Default ACL: Semantics (again)

[Andreas Gruenbacher]

James Buster wrote:
> 
> On Oct 6, 12:36pm, "Peter J. Holzer" wrote:
> } Subject: Re: Default ACL: Semantics (again)
> }
> } On 1999-10-05 13:38:44 +0200, Andreas Gruenbacher wrote:
> } > The rules suggested don't allow, for files created, to grant
> } > different rights to different users. Consider the following
> } > scenario:
> } >
> } >   User A shall be allowed to create files, but is not
> } >          allowed zo change the files created afterwards.
> } >
> } >   User B is allowed to create files, and is also allowed
> } >          to change the files afterwards.
> } >
> } > Apart from the fact that with the basic rwx set of permissions,
> } > it is possible for user A to delete and re-create files,
> }
> } It is also possible for user A to change the acl of the file after
> } creation (he is the owner of the file after all) and then write to it.
>
> Even that isn't necessary. creat() ignores both file permissions and
> ACLs when creating files. For example,
>         int fd;
>         ...
>         fd = creat("/tmp/xxx", 0);

Yes. The use of the word `afterwards' above was meant to describe a
point in time when the file has already been closed again. This
behavior of creat() is very useful in a lot of situations.

> [...] What Mr. Gruenbacher wants
> cannot be done without a fundamental change in the semantics of Unix
> file creation.

I just don't see that fundamental change in file creation semantics.


      user    group   other
 ----+-------+-------+-------+
     | r w x | r w x | r w x |
 ----+-------+-------+-------+
      ^       ^       ^
      |       |       +-- maps to ACL_OTHER_OBJ
      |       +-- maps to ACL_GROUP_OBJ or ACL_MASK_OBJ
      +-- maps to ACL_USER_OBJ

When a file is created with creat() in a directory that has
a default ACL, there are the following pieces of information:

- the mode parameter to creat()
- the mode field of the file.
- the default ACL.

The mode field of the file has to be initialized in a meaningful way.

For the owner, there are:
(A) the ACL_USER_OBJ ACL entry permission bits.
(B) the user bits in the mode field of the file.

So my understanding of the standard is:
Set both (A) and (B) to the intersection of the default ACL's
ACL_USER_OBJ entry permission bits and the ACL_MASK entry
permission bits.

Correct? Unclear? Wrong?



Let's take an example.
It doesn't matter if this example isn't very useful. I'm
first of all concerned with the mechanisms.


--------------------------- snip ---------------------------
joe at snowball:/acl/d1 > getfacl .
# file: .
# owner: agruenba
# group: users
user::rwx
group::rwx
other:rwx
default:user::---
default:user:joe:rwx
default:user:lisa:r-x
default:group::r-x
default:mask:rwx
default:other:r-x

joe at snowball:/acl/d1 > touch x
joe at snowball:/acl/d1 > getfacl x
# file: x
# owner: joe
# group: toolies
user::---
user:joe:rwx                    #effective:rw-
group::r-x                      #effective:r--
mask:rw-
other:r--

joe at snowball:/acl/d1 > cat x
cat: x: Permission denied
joe at snowball:/acl/d1 >
--------------------------- snip ---------------------------


Now the old question was why the permissions joe would
have from the `u:joe:rwx' entry shouldn't get added to the
`user::---' entry.

The result would be:

----------------------- snip (fiction) -----------------------
joe at snowball:/acl/d1 > touch x
joe at snowball:/acl/d1 > getfacl x
# file: x
# owner: joe
# group: toolies
user::rw-
user:joe:rwx                    #effective:rw-
group::r-x                      #effective:r--
mask:rw-
other:r--

joe at snowball:/acl/d1 > cat x
joe at snowball:/acl/d1 >
----------------------- snip (fiction) -----------------------


That way, it would be easy to grant another user, lisa,
different permissions on files she creates (nce she has
closed them the first time):


----------------------- snip (fiction) -----------------------
lisa at snowball:/acl/d1 > touch y
lisa at snowball:/acl/d1 > getfacl y
# file: y
# owner: lisa
# group: toolies
user::r--
user:lisa:r-x                   #effective:r--
user:joe:rwx                    #effective:rw-
group::r-x                      #effective:r--
mask:rw-
other:r--

lisa at snowball:/acl/d1 > cat y
lisa at snowball:/acl/d1 >
----------------------- snip (fiction) -----------------------


Why doesn't the standard demand this?
Why doesn't the standard even just allow this?

It's really just a small change, but makes the whole system
a lot more useful, doesn't it?


Andreas

------------------------------------------------------------------------
 Andreas Gruenbacher, Vienna University of Technology
 a.gruenbacher at infosys.tuwien.ac.at
 Contact information: http://www.infosys.tuwien.ac.at/~agruenba
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message