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