[Bugs] [Bug 1209735] FSAL_GLUSTER : symlinks are not working properly if acl is enabled

bugzilla at redhat.com bugzilla at redhat.com
Wed Jun 24 22:24:34 UTC 2015


Niels de Vos <ndevos at redhat.com> changed:

           What    |Removed                     |Added
                 CC|                            |bugs at gluster.org,
                   |                            |gluster-bugs at redhat.com,
                   |                            |pkarampu at redhat.com,
                   |                            |rabhat at redhat.com
          Component|GlusterFS FSAL              |posix
            Version|2.2                         |mainline
            Product|nfs-ganesha                 |GlusterFS

--- Comment #6 from Niels de Vos <ndevos at redhat.com> ---
Thanks for the very clear explanation of the issue!

So, we need to get the ACL on a symlink, but we only have the parent gfid and
the basename of the symlink (gotten through the handle). The symlink itself can
not be traversed (otherwise it would probably be handled as a directory, which
does not need to be correct for symlink'd files and such).

We have these components:
 - <parent-gfid> (from the loc_t structure)
 - <basename> used to build the "real_path" in the posix xlator
 - real_path (in posix xlator) being a symlink pointing to a non-existing
   (readlink returns a string that does not start with "../../")

What I think is we need to do:
 - a readlink() on the "real_path"
 - get the parent-dir through the parent-gfid (with
 - construct the <complete-path> with <parent-dir>/<readlink-result>
 - possibly repeat the above steps in case the <complete-path> is a symlink?

This seems to be a difference between lgetxattr() and acl_get_file(). For ACLs,
it is not possible to set them on a symlink, they will always be set on the
target file. Reading the ACL expects the symlink to point to the target.

This problem now got identified by fetching the ACLs, but I think setting an
ACL on a symlink will result in very similar problems.

Please have one of the posix-xlator maintainers (added on CC of this bug) check
your analysis and my proposed approach. If we are lucky, there is a function in
the posix xlator already that can convert a "real_path" broken symlink to a
correctly traversed pathname. I did not spot one that quickly, but I also did
not search long for it.

You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=99PhifxtwI&a=cc_unsubscribe

More information about the Bugs mailing list