Date: Sun, 9 Nov 1997 17:38:34 +0000 (GMT) From: Stephen Roome <steve@visint.co.uk> To: Julian Elischer <julian@FreeBSD.ORG> Cc: hackers@FreeBSD.ORG Subject: Re: How useful is this patch? Message-ID: <Pine.BSF.3.95.971109172752.2020A-100000@dylan.visint.co.uk> In-Reply-To: <199711090436.UAA26951@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 8 Nov 1997, Julian Elischer wrote: > The problem is that there are cases where one unpriveliged user needs > to put files in the 'home directories' of other users. This is OK as long > as the owner of the directory can delete them. This sounds really familiar... what you're suggesting sounds good in practice, and as a mount options thats normally off it's not too much of a problem. > Here is the hack idea. > if a mount option is specified, then setting the SUID bit > on a directory specifies similar inheritance with UIDS as we > presently have with GIDs. In other words, if the USER's home directory > is SUID, then when user B places a hierarchy of files into USER A's > directory, they become owned by user A. This corresponds exactly > with how naive PC users expect things to work. > "It's in my folder so it's mine" > The SUID bits are hereditary to child directories, and > a file 'given away' in this manner > 1/ cannot be give n to root (would defeat quotas) > 2/ has the execute bits stripped off (and suid) Okay, sounds good, what if I am in group wheel and I want to have this option set, and I have a ~/bin directory in my path. Someone could place an executable in my bin directory called "su", this could be a nice password grabber util... My ~/bin dir is last in my path so this isn't too much of a problem except with people figuring that I'm prone to typoing things like "su-" (without a space) which would be a great trojan horse. Okay, I'm quibbling, guess this only means that this system would need to ensure that files placed in other peoples directories like this can't be made executable, and certainly can't overwrite other files that are there. [I didn't get time to read the patch that carefully, so knowing my luck you've thought of this.. struck me as dangerous though.. like chown, any way of getting around ownership permissions usually ends up being root only..] > The advantage to this is that SAMBA and NETATALK, FTP and any other utilities > one may think of, suddenly all start exhibiting 'DOS-USER friendly' > behaviour, without needing to change and maintain those packages. > It can also be turned on and off > so that it would not be turned on in parts of the filesystem used by > 'real' users. You still have netatalk's problem of .Apple* files needed to just browse properly, unless all directories that should be browseable are setuid. Other than that, I get round this by exporting under samba ~ and /home/filestore/transfer/USERNAME which is chmod 777.. that's nasty and ends up with tons of "transfer directories" full of junk that no-one ever deletes.. This is the best alternative I have, so I'll probably be using your patch anyway.. Steve (quibbling) -- Steve Roome - Vision Interactive Ltd. Tel:+44(0)117 9730597 Home:+44(0)976 241342 WWW: http://dylan.visint.co.uk/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.971109172752.2020A-100000>