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 _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
