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

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1209735

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
target
   (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
posix_make_ancestryfromgfid?)
 - 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