BUG: Wide Links - does not work as documented
Cole, Timothy D.
timothy_d_cole at md.northgrum.com
Tue Apr 18 14:56:07 GMT 2000
> -----Original Message-----
> From: Jani Jaakkola [SMTP:jjaakkol at cs.helsinki.fi]
> Sent: Thursday, April 13, 2000 15:05
> To: Multiple recipients of list SAMBA-TECHNICAL
> Subject: Re: BUG: Wide Links - does not work as documented
>
> On Thu, 13 Apr 2000, Jeremy Allison wrote:
>
> > Not at all portable I'm afraid.
>
> Right. So for systems which do not have O_NOFOLLOW:
>
> 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.
>
What happens if you inadvertantly opened, say, /etc/passwd with
O_TRUNCATE? By the time you do the fstat(), you're already SOL.
Okay, let's say instead of using O_TRUNCATE, you use ftruncate(2)
after the fstat()/lstat() check... only, then you've got a potential race
between the open() and the ftruncate(), if some software relies on the
open/truncate operation being atomic...
This is not an easy thing.
> That will be a lot of syscalls and complexity for a simple thing. Symlinks
> and security don't mix well :(
>
Eh, the real problem is that we don't have enough control over the
process' view of the filesystem namespace.
> Does anybody know a better way to do the same thing?
>
no, unfortunately.
> Is there anybody else besides me, who would need a feature like this?
>
yes.
Unfortunately, Samba still needs to access some files outside of the
exported portion of the filesystem namespace, or we could use chroot().
More information about the samba-technical
mailing list