On Fri, Sep 30, 2022 at 5:06 AM Miklos Szeredi [off-list ref] wrote:

On Fri, 30 Sept 2022 at 11:09, Christian Brauner [off-list ref] wrote:

quoted

On Fri, Sep 30, 2022 at 10:53:05AM +0200, Miklos Szeredi wrote:

quoted

On Thu, 29 Sept 2022 at 17:31, Christian Brauner [off-list ref] wrote:

quoted

This adds a new ->get_acl() inode operations which takes a dentry
argument which filesystems such as 9p, cifs, and overlayfs can implement
to get posix acls.

...

quoted

quoted

So what's the difference and why do we need both?  If one can retrive
the acl without dentry, then why do we need the one with the dentry?

The ->get_inode_acl() method is called during generic_permission() and
inode_permission() both of which are called from various filesystems in
their ->permission inode operations. There's no dentry available during
the permission inode operation and there are filesystems like 9p and
cifs that need a dentry.

This doesn't answer the question about why we need two for overlayfs
and what's the difference between them.

quoted

quoted

If a filesystem cannot implement a get_acl() without a dentry, then
what will happen to caller's that don't have a dentry?

This happens today for cifs where posix acls can be created and read but
they cannot be used for permission checking where no inode is available.
New filesystems shouldn't have this issue.

Can you give an example of this?   How can you read an ACL without an
inode or open file struct?  ACL wouldn't fit in a dentry right?  By
the way there is an option that we can use on open to return the
"maximal access" that that user/group has for the file (a 32 bit mask
showing whether the effective user has read, write, append, read
attributes, write acl etc. permissions).  Would this be helpful for
you to have us do when you revalidate dentries?

That's weird, how does it make sense to set acl on a filesystem that
cannot use it for permission checking?   Maybe the permission checking
is done by the server?

Steve?

It doesn't do much good to check if user1 on client1 can access the
file on server if any user on client2 can access the file - unless the
server is checking ACLs, so the server checks are the more important
ones.

The permission checking on the client doesn't really matter in many
scenarios (the security checks that matter are usually only on the
server).    The ACLs are stored on the server and evaluated by the
server so duplicating ACL evaluation on BOTH client and server only
helps in cases where the server doesn't know who the local Linux user
is (e.g. single user mounts - where all local users use the same
authenticated session).  It is common e.g. to mount with "noperm"
mount option - in which case the client checks are turned off (since
the server ones are the checks that matter the most).

Note that the SMB3 protocol (and also NFSv4.1/4.2) support a richer
ACL model on the server that is more secure (or at least more
granular) in some scenarios than the simpler POSIX ACL model.

Are there examples of how this would work for the richacl examples
(e.g. NFSv4.1/4.2 or cifs.ko or NTFS or ...)?


-- 
Thanks,

Steve