Date: Sun, 9 Nov 1997 17:23:10 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: David Greenman <dg@root.com> Cc: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, hackers@FreeBSD.ORG Subject: Re: How useful is this patch? Message-ID: <Pine.BSF.3.95.971109170848.5649B-100000@current1.whistle.com> In-Reply-To: <199711092315.PAA27471@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
of course, but who said that you have to enable it in you HOME directory? We want to do this in users 'dropbox' directories which is not the same as their ho,e directories. without it there is a never-ending set of complaints about permissions, and the admin spends a lot of time removing files for users. As is indicated.. this is implemented as a mount option (default off) and the directory in question must have the bit set.. it isn't likely to happen by accident. We can keep it as a WHISTLE-ONLY mod here, but I thought I'd see if anyone else wants it.. I'd rather have it in the general sources than proprietary, but That's a decision that's beyond me to make.. (i.e. yours). On Sun, 9 Nov 1997, David Greenman wrote: > >As Julian Elischer wrote: > > > >> 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. > > > >As long as it's a mount option (defaulting to off), i think i could > >live with it. > > > >> 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) > > > >Problem: you can cause someone else a DoS attack by maliciously > >filling his home directory. It doesn't make any differnce about who can write to the directory. it just changes who OWNS it. the previous behaviour is more of a DOS attack because the user may not be able to DELETE things that are owned by others. The user can now just delete it. > > > >(I didn't review the patch itself, so i explicitly don't comment on > >stylistic etc. bugs. Make sure the style adhers to the requirements > >of style(9).) > > You could also create a .rhosts file, allowing anyone to log in as the > user. You could also create a variety of other files like .tcshrc if it > didn't already exist and the user's shell was tcsh (and similar other login > scripts with other shells), or various X resource files if the user might > start X apps. The list goes on and on. I think it sounds like a major > security hole for just about anyone who enables it. How many of these check the owner now? .rhosts is a security hole anyhow, and in any case I think that doing this on a home directory would be foolish. it doesn't change who CAN write, just who ends up owning the file.. I certainly don't think it should be default anywhere. We want it for the thousands of 'unwitting' FreeBSD users we have, using it through SAMBA and Netatalk. julian > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.971109170848.5649B-100000>