non-superuser chown(2)s considered harmful

[Daniel A. Graifer]

In article <1990Dec11.101909.10851 at kithrup.COM> sef at kithrup.COM (Sean Eric Fagan) writes:
>
>I prefer the control you get from a proper implementation of ACL's.  See
>Elxsi's EMBOS for an example.  (Normal ACL's, an extension of Unix's rwx
>philosophy, with users and groups; passwords for files [I forget whether
>different users could have different passwords; I think so], and the ability
>to specify that a file can only be accessed using a program from a given
>program list [*neat*; I couldn't think of a normal use for SUID programs
>under embos given that!].)

It's been awhile, but at least in the late '70s, the Burroughs large
systems (Now unisys A-series) files had a 'security' attribute (amoung
many other attributes such as 'filekind', sort of like unix's filename
.suffix conventions, but more universal) which could be 'PRIVATE', 'CLASSA'
(ie public) or 'CLASSB'.  If a file was security=CLASSB, then another
attribute specified the name of a GUARDFILE, which specified which user
/program combinations could have what kind of access under what circumstances.
There was a whole structured language for specifying this, and a guardfile
compiler to translate this into efficient guardfiles.  There wasn't much
you couldn't do with it.  In particular note the efficiency of pointing
many file's guardfile attributes at the same guardfile.  The guardfiles
could themselves be protected by other guardfiles.

This is off the subject of unix internals, but Burroughs had a lot of the
elements in place for an 'object-oriented' file system clear back in the
early '70s.  If we're going to talk about where we'd like unix to go, there
are previous successful experiances to guide us.

Dan
---