Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Jan 2001 20:32:18 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        dwhite@resnet.uoregon.edu (Doug White)
Cc:        walton@onlinemusic.com (Dave Walton), freebsd-fs@FreeBSD.ORG
Subject:   Re: suiddir and samba
Message-ID:  <200101252032.NAA27330@usr08.primenet.com>
In-Reply-To: <Pine.BSF.4.21.0101242319270.25771-100000@resnet.uoregon.edu> from "Doug White" at Jan 24, 2001 11:25:22 PM

next in thread | previous in thread | raw e-mail | index | archive | help
> Hm .. suiddir makes files inherits the perms AND owner/group from the
> parent dir.  This is kinda evil as it essentially is a hardwired file
> giveaway, which is a BSD no-no.  You should just set the dir
> group-writable and add all the user's to the parent dir's group.  
> 
> I suppose if you *really*really* want the owner to propagate, then use
> suiddir. Of course, unless you hack Samba the suid bit won't get set on
> subdirectories.

The problem this was intended to address is a shared per user
filespace, which is exposed via multiple spaces (e.g. SMB,
AppleTalk, FTP, WWW, etc.).

The problem with _not_ doing this is that SMB can be made to
do the least astonishing thing, which is give ownership of
files to the user who owns the filespace.  UNIX will let you
delete files not owned by you, but placed in a directory
owned by you.

Consider now that you have this filespace owned by "fred", and
a file is created there via SMB, with appropriate options:
it will also be owned by "fred", the owner of the filespace.

Now FTP something up there.  It will be owned by the user
logged in for the ftp session (whatever the current credential
of the ftpd is at the time).  Attempts by "fred" to delete
this file from his filespace via SMB will fail.  A similar
problem is created if instead of being put there via FTP,
the file is put there via AppleTalk.  A similar problem also
occurs if this is a UNIX shell user, writing a file into a
writeable directory belonging to an SMB user.

Now consider that "fred" is a Windows client user, and the
person providing the file to "fred" is a UNIX or Macintosh
user, and you will see the problem this is trying to (and
does) solve.

PS: I wasn't involved in the actual implementation, that was
Julian, but I agree with him that it makes more sense to
change the FS semantics than it does to have to hack every
possible program to know about "dropbox"-style file giveaway
semantics.

PPS: I really can't see another way to allow a shell user,
since the transaction is not intermediated by a daemon, to
write files into the "fred" filespace, which is really the
most simple Windows/UNIX interoperability scenario possible.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101252032.NAA27330>