BUG: Wide Links - does not work as documented

Mayers, P J p.mayers at ic.ac.uk
Wed Apr 19 15:31:31 GMT 2000

I was under the impression chroot'ing back out was impossible.



The world is divided into two kinds of people, those who divide the world
into two kinds of people, and those who don't... 

-----Original Message-----
From: Peter Samuelson [mailto:peter at cadcamlab.org]
Sent: Friday, April 14, 2000 11:37 PM
To: Multiple recipients of list SAMBA-TECHNICAL
Subject: Re: BUG: Wide Links - does not work as documented

[Jani Jaakkola]
> 1. lstat() the filename. If it is a symlink, return failure
> 2. open the file (without O_NOFOLLOW)
> 3. fstat() the filedescriptor returned by open.
> 4. If the fstat() and lstat() did not agree (they did not point to same
>    inode), we had a race condition situation. Close the
>    already opened file and return failure. 

Yeah.  Because symlinks are a Unix kernel feature.  If they had been
done entirely in userspace, like Windows shortcuts are, they would be
easy to disable.  All in all, I prefer the Unix approach in this case.

In my opinion, though, the race condition isn't a problem and shouldn't
be fixed.  Because it breaks down to two access cases: the user has
local (Unix shell) access to the directory the share is in, or he
doesn't.  If he doesn't, he won't be able to create or manipulate
symlinks anyway, so you have no problem.  If he does, he doesn't need

> That will be a lot of syscalls and complexity for a simple
> thing. Symlinks and security don't mix well :(

Depends on what you mean by security.  I don't consider the ability to
follow a symbolic link to be a security hole.  From a Unix shell
perspective, it doesn't allow you to read, write, delete, rename,
etc. any files or directories that you otherwise couldn't.

> Does anybody know a better way to do the same thing?

If `wide links=no' *really* makes you feel better, even when you have
users with local shell access to your Unix host (otherwise how could
they create symlinks in the first place?  Not through SMB...), you
should use chroot().  That is what most ftpds do for anonymous FTP.  I
haven't looked at the source for this -- after an SMB session is set
up, does smbd really *need* access to files outside the share?  If it's
really necessary, the process can become_root() then chroot() back


More information about the samba-technical mailing list