Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!rochester!kodak!gizzmo!lazlo!ccs
From: ccs@lazlo.UUCP (Clifford C. Skolnick)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Message-ID: <184@lazlo.UUCP>
Date: 7 Jul 89 03:30:04 GMT
References: <20037@adm.BRL.MIL> <205@marvin.moncam.co.uk> <1035@riddle.UUCP> <8906272337.AA24210@cscwam.UMD.EDU> <214@tnl.UUCP>
Reply-To: ccs@lazlo.UUCP (Clifford C. Skolnick)
Organization: The Steam Tunnel, Henrietta, NY
Lines: 25

In article <214@tnl.UUCP> norstar@tnl.UUCP (Daniel Ray) writes:
|In article <8906272337.AA24210@cscwam.UMD.EDU>, stripes@wam.UMD.EDU writes:
|> ...
|> I would like to see a few extra protection bits in the new Kernal.  A bit
|> for append-only (the kernal fseeks to the end of the file before each write).
|
|  1. A new (or new use of a) directory permission bit, such as using SUID/SGID
|or something new, would designate the dir as "append only except edit in
|single user mode". This would apply to root as well. So, audit trails and
|logfiles could not be modified except when the machine was brought down to
|single user mode at the local console. Files in the dir could be appended
|to, however, if the mode on the file permitted writes. Existing data could
|not be modified by anyone in multiuser mode.

If I was the superuser, I could just wipe out the raw disk devices.  The
only way this will work is to use an on-line printer.  The whole concept
of a super-user is the problem.  I wish I had a better solution to offer,
but...

			Cliff
-- 
 "I'd rather stay here with all the madmen, than perish with the sad man
 roaming free" -- David Bowie
"Life is a test, only a test.  If it was real, you would have been given much
better instructions." Clifford C. Skolnick / (716)427-8046 / ccs@lazlo.UUCP