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

[jont at us.ibm.com]

A common theme of the ideas I want to borrow from WinNT's ACL model
is to reduce the powers of god (or a PMT suffering BOFH :-).

Posix.1e Kernel capabilities play divide and conquer on gods abiilities.
I favour obsoleting them (as many as we can) by giving limited and
auditable versions to all users thus allowing us to remove the
corresponding god only features.

The two Im picking on here are chown and the sticky bit on directories.

[ Another obvious target is mknod for physical devices - devfs. ]

But back to the thread of the topic ...

In the dim dark ages (ie before lunch :-) I wrote some things
to which something, perhaps Ilmar Habibulin's email agent, responded ...

> > 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.

| Why not to choose Novell? ;-)

Ive never used Novell permissions, and the vague recollection I have
of looking at a second hand implementation for Linux (based on a
mechanism that looked like DTE) left me feeling there was something
missing.
But the memory is foggy and it was a second hand view of Novell
permissions.

> take-owner: For those who aren't familiar with it, WinNT provides a
> take-owner permission which is basically saying that the specified
> user mayy chown the file to themselves.  Thus chown only exists as a
> two party agreement (previous and new owner) avoiding many of the
> security problems of early Unix chown's. Whats more if the
> administrator forciably takes-ownership the user can see it because
> they no longer own the file - improved accountability. [ modulo
> manipulating backups ]

| IMHO, take ownship suxx. I can't imagine the data processing model,
| which will require such a strange permition. It maybe a capability,
| but not an ACL permition.

Many early versions of chown were not restricted to root.
This provided an excellent attack on the quota system. I never, ..., honest
:-)
The solution was like using an axe not a chisel:
  rather than make it secure they removed it from normal use.

So the questions become:

a) do we want a secure transfer of ownership ?

b) is there a better way than take-owner ?




> change-perm: Allows 'system' to own directories which are used by
> users basically under the users control (personalised /tmp or mail
> files or ...)

| Don't understand this sentence.
| Doesn't standard unix permitions model allow this?

Standard unix permissions are ugo+rwx[t] and they either allow
very little or too much, depending on your perspective. :-)

Under a std unix model only an owner can set the file permissions.
With change-perm I can delegate that activity without giving up ownership.
So it may help to think of change-perm as splitting the privileges
of ownership available under unix.

I'll try to explain by example ...

Using change-perm, as a normal user I can make a directory available to
another and allow them considerable (but not full) control.
By retaining ownership of the directory I can ensure that they cannot
lock me out.  Unix achieves vaguely similar results with the sticky bit,
but that applies to root not to normal users.

- 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


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