[Gluster-devel] Problems about acl_get_file used in posix_pacl_get

[Niels de Vos]

On Fri, Aug 17, 2018 at 05:22:17PM +0800, Kinglong Mee wrote:
> Hi Niels,
> 
> On 2018/8/17 17:13, Niels de Vos wrote:
> > On Fri, Aug 17, 2018 at 03:04:43PM +0800, Kinglong Mee wrote:
> >> Hello folks,
> >>
> >> nfs-ganesha using the new gfapi named glfs_h_acl_set/glfs_h_acl_get,
> >> at xlator posix, glusterfsd calls acl_get_file/acl_set_file (libacl functions) to process xattrs.
> >>
> >> By default, sys_lsetxattr/sys_llistxattr/sys_lgetxattr/sys_lremovexattr are used to process xattrs.
> >> But, unfortunately, those two functions do syscall by getxattr/setxattr.
> >> I don't think that is we want.
> >>
> >> Is it a known problem ?
> > 
> > There should not be a problem for libacl to use syscalls directly. The
> > Gluster sources use sys_<syscall> so that there can be wrappers for the
> > differences between OS's. In the end, these sys_<syscall> functions will
> > mostly call the <syscall> with (adapted) arguments.
> > 
> > I do not know what problem you are facing, but I can imagine that there
> > is a 'getxattr' symbol in the executable image that gets called by
> > libacl, instead of the 'getxattr' syscall. This will likely result in
> > very strange behaviour, if not segfaults.
> 
> Sorry for my unclear description.
> The real problem here is libacl gets/sets xattrs by getxattr/setxattr which follow symbolic links,
> but, posix xlator get/set xattrs by sys_l*xattr which do not follow symbolic links.

Permission checking is done by the kernel. I do not think setting ACLs
on a symlink makes much sense. More liberal permissions on the symlink
will not help with accessing the contents, and restricting permissions
on a symlink still give the user to access the contents through its real
filename.

Is there a reason that having ACLs on a symlink can have benefits?

Niels