rwx in ACLs (was Re: extattr in-kernel interface)

jont at us.ibm.com jont at us.ibm.com
Wed Apr 19 16:11:30 GMT 2000



Someone or something purporting to be Kris Kennaway raised some excellent
points.

I think you are right on almost all counts, though I wish to raise two
points.

1) one side effect of MLS systems is that low users cannot see high files,
so
   the invisibility of files is something that a B1 has to deal with ...

2) we need to find a balance between too few permissions (eg rwx) and too
many,
   to avoid confusing/scaring/dumbfounding users.  In ACM RBAC '99 I had a
paper
   which 'recommended' hierarchical structures (trees) of rights to begin
to
   address the problem of too many rights (my example included a rename
right :-).

Does the idea of a hierarchy of rights appeal ?
Does anybody think it will help ?
Other comments ...

- JonT

---
Jon Tidswell
Advanced OS Technology Group / Sawmill Linux Project
IBM TJ Watson Research Center 30 Saw Mill River Road, Hawthorne, N.Y. 10532

Email: jont at us.ibm.com   Voice: +1 914 784 7550

------------------------------

On Tue, 18 Apr 2000 jont at us.ibm.com wrote:

> > Do you still plan to use rwx model for ACLs?
>
> _I_ hope he plans to do something akin to the WinNT model[1]:
>     read, write, append, delete, execute, take-owner, change-perm.

It depends how far we want to go, but there's an argument for having an
ACL for each of the file-access syscalls. In addition to the above list,
there are:

* rename

If I can write to a file but not delete it, I can truncate it to zero
length but the file itself is still there. But I can still possibly hide
the file amongst others by renaming it with the rename() syscall and
creating another in its place. The rename could be prohibited by a write
acl on the parent directory, though, but conceivably not in all cases
(e.g. a directory which contains files created dynamically by a daemon)

* chflags

This is probably going to be mostly redundant with ACLs, but seem to be a
still-useful flag or two (opaque/nodump/archived/etc). File flags are
something which needs to be thought about for the new world order.

* stat

It might break things unexpectedly if users cannot stat files, however.

A further (and more likely to break :-) possibility is if we made it so
users could not even see the existence of a file if they don't pass a
"visible" ACL element. I don't know how feasible this is, though.

There might be other applicable syscalls I've missed.

Kris



To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message



More information about the trustedbsd-discuss mailing list