Date: Tue, 27 May 1997 20:48:25 -0700 From: "M.R.Murphy" <mrm@Mole.ORG> To: beattie@stt3.com, julian@whistle.com Cc: current@FreeBSD.ORG, julian@FreeBSD.ORG, mckusick@vangogh.cs.berkeley.edu Subject: Re: NEW FEATURE. BSD file NOUNLINK flag. RFC.. will commit unless.... Message-ID: <199705280348.UAA03107@meerkat.mole.org>
next in thread | raw e-mail | index | archive | help
> From owner-freebsd-current@FreeBSD.ORG Tue May 27 18:54:41 1997 > Date: Tue, 27 May 1997 18:12:20 -0700 > From: Julian Elischer <julian@whistle.com> > To: Brian Beattie <beattie@stt3.com> > CC: Julian Elischer <julian@FreeBSD.ORG>, current@FreeBSD.ORG, > mckusick@vangogh.cs.berkeley.edu > Subject: Re: NEW FEATURE. BSD file NOUNLINK flag. RFC.. will commit unless.... > > Brian Beattie wrote: > > > > On Sun, 25 May 1997, Julian Elischer wrote: > > > > > > > > I would like feedback on a new feature I want to add to the > > > filesystem code. > > > > > > In addition to the immutible and append flags, we at whistle are > > > using a flag NOUNLINK > > > > > > The action of this flag is to allow the file or dir in question > > > to be modified in any way but never deleted. > > > > I would be opposed to this as, unlike the immutible flag, I can not see > > how is adds to the robustness or security of the system. It adds yet > > another hidden control and contributes to bloat and feeping creaturisim. > > If this must be added it should be an kernel config option, normally off. > > > > I can see "Unremovable file ... even when I log into the system as root I > > can not remove this file ... !$%*^)^$# FreeBSD sucks". > > immutible already gives you this.. > > > > > Matbe if somebody could explain how this fixes some major problem I might > > feel differently. > well its'a MAJOR problem for US as we a re trying to turn freeBSD into > an > embedded OS in a 'appliance'.. see www.whistle.com > > once again.... > > > OK here is the picture > > we have several users. > all untrusted. > some must be in a group 'admin' that allows them to write to and delete > anything > in a certain subtree.. EXCEPT a skeleton hierarchy of directories. > > When the system is in administration mode, the REAL admin (root in > single-user) > can add to and change that skeleton hierarchy. All users must be able to > write to their own directories in the hierarchy (and delete). > > So far, if we have a group 'admin', then users in that group > can do things an admin should be able to do if the whole hierarchy > has a group of admin. HOWEVER these are UNTRUSTED admins, and must not > be > able to delete parts of the essential skeleton hierarchy. > > With a NOUNLINK bit we can nail down the hierarchy when in 'real' admin > mode, and the 'untrusted' admins can't smash it. As a side note, > they are running through the netatalk, samba and ftp interfaces and > don't see 'unix' as such. > The trouble with IMMUTIBLE and APPEND is that they don't allow the users > to > create and delete their own files freely within the established > hierarchy. > > The sticky bit is CLOSE, but we run into trouble with more than one user > with > admin privs because they can't un-do each other's damage. > > To your comment.. This is no more 'annoying' than the 'IMMUTIBLE' flag > that presently does even more.. > > personally I think it complements the other flags quite well. > > comments? > I'd prefer not to see a feature like this added to the general code base. If one wishes to add ACL's, why then, add ACL's. Otherwise, solve the problem with the exsisting toolset. Then, again, that's just my preference. Why someone shouldn't change the code for everyone to make it easier to make a particular applicance for some folk is not mine to say. I would say, though, that if you want special tools for a special appliance, then build the special tools, and restrict the general tools. It's an application policy problem, not a system problem. Hrrrumph. Feeping creaturism. -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705280348.UAA03107>