faulty symlinks on mounted samba volumes

Bug #542005 reported by Joel Gabor
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
samba (Ubuntu)
Invalid
Medium
Unassigned
Nominated for Lucid by Joel Gabor

Bug Description

Binary package hint: samba

After upgrade to Lucid the samba clients can't open symlinked directories any more.
The following related options are added to /etc/samba/smb.conf :
follow symlinks = yes
wide symlinks = yes
unix extensions = no

When I try to list this symlinked directory with ls -la /media/samba/, one time it appears:
.....
drwxr-xr-x 0 root root 0 2010-02-05 12:09 sdb7
.....
then if I run ls -la /media/samba/ second time, the output is:
.....
d????????? ? ? ? ? ? sdb7
.....
continuing to list it, with ls -la /media/samba/, the output is the first again (drwxr-xr-x 0 root root 0 2010-02-05 12:09 sdb7), then the second (d????????? ? ? ? ? ? sdb7) ... etc. Like a semaphore. :-)
No way to change to sdb7 directory.

The sdb7 is linked outside the user's home.
ls -la /home/joe/
.....
lrwxrwxrwx 1 joe joe 24 2009-01-18 23:11 sdb7 -> /media/sdb7/data/vol0/
.....

However there is no problem with directories that linked inside user joe's home.
 (Like: lrwxrwxrwx 1 joe joe 35 2008-04-13 21:45 TransGaming_Drive -> /home/joe/.cedega/GFSGL//c_drive )
I can change to that 'TransGaming_Drive' directory on mounted samba volume without problem.

$ lsb_release -rd:
Description: Ubuntu lucid (development branch)
Release: 10.04

$ apt-cache policy samba:
samba:
  Installed: 2:3.4.6~dfsg-1ubuntu2
  Candidate: 2:3.4.6~dfsg-1ubuntu2
  Version table:
 *** 2:3.4.6~dfsg-1ubuntu2 0
        500 http://de.archive.ubuntu.com/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status

$ apt-cache policy samba-common
samba-common:
  Installed: 2:3.4.6~dfsg-1ubuntu2
  Candidate: 2:3.4.6~dfsg-1ubuntu2
  Version table:
 *** 2:3.4.6~dfsg-1ubuntu2 0
        500 http://de.archive.ubuntu.com/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status

Tags: samba

CVE References

Joel Gabor (joelgabor)
description: updated
Revision history for this message
Chuck Short (zulcss) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it without more information.

Please include the information requested at https://wiki.ubuntu.com/DebuggingSamba#samba-client.

Changed in samba (Ubuntu):
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
Russ W. Knize (rknize) wrote :

The problem is a copy-paste error from a solution presented in one of the forums. You want:

wide links = yes

(not wide symlinks)

Russ

Lightning (lightning)
Changed in samba (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Lightning (lightning) wrote :

I've experienced this (or something same) recently too on 9.10 server, Samba 3.4.0.
I'm not sure since when is this lasting but I think upgrading the devicekit-* package today might caused it.?
That was the last thing I did before noticed this bug...

It only affects symlinks and only on certain filesystems with "unix extensions" enabled.
Without "unix extensions" symlinks works everywhere, otherwise only on one of all my file systems.
The file systems are on software raid arrays and the're ext4.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Starting with samba 3.4.6, "wide links" gets disabled automatically if "unix extensions" are enabled. This is by design to resolve a security issue.

See:

http://www.samba.org/samba/history/samba-3.4.6.html

and

https://bugzilla.samba.org/show_bug.cgi?id=7104

and

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0926

Revision history for this message
Lightning (lightning) wrote :

In my case "wide links" is disabled ever since I use Samba. The ordinary symlink doesn't work if "unix extension" is enabled at the same time. By doesn't work I mean they don't have any file permissions or even details just '?' marks instead. It's been working until yesterday...

I'll be more specific: On the local system every symlink work. On the drive named md1 there is no sign of this bug via Samba either (unix extension enabled too). But on the drive md3 and sde1 symlinks don't work via Samba. I ran e2fsck (-f) and It found nothing. All of the mentioned drives has ext4 filesystem which were updated from ext3.
I'm only guessing this is a Samba only bug...

Revision history for this message
Thierry Carrez (ttx) wrote :

Could you provide the information asked at comment 1.

In particular, how do you access the share ? I suspect it's not using smbclient but using a CIFS mount, could you confirm, and provide the options used in that mount ?

I tried accessing a share with symlinks with smbclient and it seems to work alright.
I mounted a share with symlink with "sudo mount -t cifs //SRV/SHARE -o user=USER,password=PASS /tmp/mee" and I could also see the symlinked dir properly.

Changed in samba (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Lightning (lightning) wrote :

Of course, even more:
smb.conf: http://pastebin.com/96W66mun

Versions:
libpam-smbpass 2:3.4.0-3ubuntu5.6
libsmbclient 2:3.4.0-3ubuntu5.6
libwbclient0 2:3.4.0-3ubuntu5.6
samba 2:3.4.0-3ubuntu5.6
samba-common 2:3.4.0-3ubuntu5.6
samba-common-bin 2:3.4.0-3ubuntu5.6
samba-doc 2:3.4.0-3ubuntu5.6
smbclient 2:3.4.0-3ubuntu5.6
smbfs 2:3.4.0-3ubuntu5.6
winbind 2:3.4.0-3ubuntu5.6

For mount I used mount.cifs (from fstab, and only with 'username' and 'password' options), also Nautilus and WinXP - Win7. None of them works.

As I said before the weirdest thing is that symlinks on one particular filesystem/partition works but all the others don't get any details about symlinks (only) viasamba...

Chuck Short (zulcss)
Changed in samba (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Thierry Carrez (ttx) wrote :

@Lightning:
Could you post an example of a symlink that fails with the smb.conf you attached ?

Revision history for this message
Lightning (lightning) wrote :

I don't get it what example you're exactly expecting but here is the full story:
I have 4 software raid arrays of 2 hard drives. (So md0 is the system's, md1 and md2 are storages, and md3 is for a kvm guest.)
Symlinks already existed and newly created work properly on md1, only inside the partition despite who owns them.
Symlinks pointed to somewhere on md0 or md2 just don't, not matter where they are or which user owns them.
Linux clients don't "see" the owner (not even numbers) and the attributes so "ls -l" shows only "?" marks for every details.
Windows clients just say "access denied".

In case it matters the filesystems on the system is ext3, on the storages are ext4.
As far as I know that md1 ain't different in any way. Only Samba's having trouble with symlinks...
For now I've turned off unix extensions, I don't really need it.

Revision history for this message
Thierry Carrez (ttx) wrote :

My understanding is that the link on md1 is a filesystem-local link, while links to md0 and md2 are wide links, which now get automatically disabled if unix extensions is on. That would explain why everything gets fixed when you disable unix extensions.

If I'm right, then this is not a bug. If you think I'm wrong, please attach the output of "mount" and then ls -l of a link that works, and a link that doesn't (so that I can see where it points to), all from the server itself (not through the samba share).

Revision history for this message
Lightning (lightning) wrote :

I checked, You're right. It confused me that this have been changed just like that in the next version (for me) .
But the question is still there: Why can't unix extension and wide links work together?
I know it a security hole, but I really need this option one way or another.

Revision history for this message
Thierry Carrez (ttx) wrote :

Please see https://bugzilla.samba.org/show_bug.cgi?id=7104 for the details. Upstream has declared these options incompatible and that's how they fixed that security issue.

Changed in samba (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.