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