[Fwd] default acl for directory

[Dancho Penev]

I moved this thread from freebsd-hackers as suggest Robert.

On Mon, Nov 25, 2002 at 10:41:21AM -0500, Robert Watson wrote:
>Date: Mon, 25 Nov 2002 10:41:21 -0500 (EST)
>From: Robert Watson <rwatson at FreeBSD.ORG>
>To: Dancho Penev <dpenev at mail.bg>
>Cc: freebsd-hackers at FreeBSD.ORG
>Subject: Re: default acl for directory
>
>
>On Sat, 23 Nov 2002, Dancho Penev wrote:
>
>> I was played with acl and specially default acl for directories at my
>> FreeBSD-CURRENT machine with UFS2 filesystem and some questions appears
>> to me: 
>> 
>> 1. How about default acl permission to override umask?  Is that the idea
>> who isn't yet implemented or you have opinions against that. 
>
>My reading of the POSIX.1e spec was that umask would continue to mask ACLs
>in the same manner it masked permissions.  However, you're welcome to

First I must say that I'm not vary familiar with POSIX.1e draft, I was
look at it only for general principles. So the next that I'll say must
not be consider as professional statement, it's just my opinion.
And now to question: Umask is a something global and must continiue to
be global in acl context, while default acl are local, they exist for
realization of some specific task. You set umask to something for
example 022 and it's valid mask to all newly created files, you give
so much rights as much require most confidencial information. Because
there is only one umask for all cases permission is mostly restrictive
to match mainly private files as well as files that are not so secret.
Now when acl exist we can continuie to use umask for global mask but when
we want to do something special we will use default acl per directory to
give for example for owner group rights to write in files only in that
directory. The question who will precede is not a such big problem,
because now with acl we have more freedom of action, but basis to thing
in this way give me the specification for cp(1):

[snip]
87 new files are created using open(), specifying the file permission
bits of the
88 source file in the mode argument, and POSIX.1e specifies the impact
of default
89 ACLs on open(). The result being that if there is a default ACL on
the destina-
90 tion directory, the resulting ACL on the destination file will be
the default
91 ACL modified by the permission bits of the source file. This
effectively will
92 limit access to the newly created file to the minimum of accesses
specified in
93 the default ACL and the source file permissions. If the destination
directory
94 does not have a default ACL, then the permission bits of the newly
created file
95 will be the source file permission bits as modified by the umask.
[snip]

>re-read the spec, or e-mail the POSIX.1e mailing list, and let us know
>if the result looks different to you :-).  The idea, btw, I suspect, is
>that this provides maximum compatibility for applications that understand
>only permissions and not full ACLs.
>
>> 2. What are reasons to update ACL_MASK entry (if exist) or ACL_GROUP_OBJ
>> entry (if mask doesn't exist) but not both in ufs_sync_acl_from_inode()?
>> 
>> It's true that reverse function ufs_sync_inode_from_acl() uses the same
>> logic but take a look at follow situation: 
>
>This is another POSIX.1e-ism, and our implementation is based on a reading
>of that draft spec.  If you want to give it a reading, or query the
>POSIX.1e list for clarification, I'd welcome any investigation of the
>issue.  My understanding is that the goal of the mask is to match the
>semantics of the permissions group entry in the traditional inode
>protections for applications that don't understand ACLs.  I.e., suppose an
>application creates a file, then chmods it 0600 -- the application wants
>the owner, and only the owner, to have read and write access.  If a mask
>entry is present (and it is required if there is ever any other extended
>entry), then we update the mask entry in the chmod(), which in effect
>leads to the same result: it masks all entries but the owner and the other
>entry.  If there's no mask entry, then there are no extended entries, so


I'm in agreement with yours argument that in this case inode group
permission and mask are one thing but if you take a look at primer that
I give, if we don't update group entry as result we will have two
different permissions for owner group in inode and in acl.


>we actually change the group protections.  If the implementation of this
>logic looks incorrect, please let me know.  Also, feel free to read the
>spec and e-mail the list and see if this actually is a sensical
>interpretation of the spec.
>
>Thanks,
>
>Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
>robert at fledge.watson.org      Network Associates Laboratories
>
>

-- 
Regards,
D. Penev

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