BUG: Wide Links - does not work as documented

[Peter Samuelson]

[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
Samba.

> 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
out....

Peter