Bug 798716

Summary: xattr namespace flipping is broken for symlinks
Product: [Community] GlusterFS Reporter: Csaba Henk <csaba>
Component: fuseAssignee: Csaba Henk <csaba>
Status: CLOSED CURRENTRELEASE QA Contact: Vijaykumar Koppad <vkoppad>
Severity: unspecified Docs Contact:
Priority: high    
Version: mainlineCC: amarts, bbandari, gluster-bugs, shaines, vkoppad
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glusterfs-3.4.0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 848324 (view as bug list) Environment:
Last Closed: 2013-07-24 17:11:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 848324, 858444    

Description Csaba Henk 2012-02-29 16:12:20 UTC
Description of problem:

Setting xtimes on symlinks fail in service user owned maintenance mounts (the kind that's used by unprivileged gsyncd)

Version-Release number of selected component (if applicable):


How reproducible:

Deterministically.

Steps to Reproduce:
1. Set up mountbroker service for geo-replication as discussed in

https://docspace.corp.redhat.com/docs/DOC-93046#for-gluster-slaves-uprivileged-agent
2. Start glusterd with respective volfile.
3. Get a mount from mountbroker service with

  gluster system:: mount <user> volfile-server=localhost volfile-id=<volname>
client-pid=-1 user-map-root=<user>
'xlator-option=*-dht.assert-no-child-down=true'

(in the example at referred place, <user> is "geonobody" and <volname> is
"slavevol").
4. login/su/sudo to <user> and cd to the mountpoint provided by mountbroker.
5. Create a symlink:

ln -s foon fool
6. Run:

setfattr -h -n "user.glusterfs.688de47f-6cc3-4ad1-b336-f1c9b0a4dcb2.xtime" -v foo fool; echo $?
  
Actual results:

setfattr: fool: Operation not permitted
1

Expected results:

0

Additional info:

A sample line from strace log of an unprivileged slave gsyncd:

lsetxattr("./f1.txt", "user.glusterfs.688de47f-6cc3-4ad1-b336-f1c9b0a4dcb2.xtime", "ON78\x00\x0d\xaf\xcb", 8, 0) = -1 EPERM (Operation not permitted)

Comment 1 Csaba Henk 2012-03-01 07:02:30 UTC
Actually there is no need to fiddle with mountbroker to reproduce the issue. We can call glusterfs directly, like

glusterfs --volfile-server=localhost --volfile-id=<volname> --client-pid=-1 --user-map-root=<user> <mountpoint>

 * * *

Further observation: for symlinks, the user.*.xtime attribute is not even flipped to trusted namespace internally. If glusterfs is invoked with debug log level,
setting such an xattr on a regular file induces the following log messages:

[2012-02-29 22:54:54.505596] D [fuse-helpers.c:484:fuse_flip_xattr_ns] 0-glusterfs-fuse: PID: -1, checking xattr(s): volume-mark*, *xtime
[2012-02-29 22:54:54.505661] D [fuse-helpers.c:502:fuse_flip_xattr_ns] 0-glusterfs-fuse: flipping user.glusterfs.688de47f-6cc3-4ad1-b336-f1c9b0a4dcb2.xtime to trusted equivalent

Now, doing this for a symlink, these messages don't come. That in itself is weird and most likely bogus, but I cannot see how it's related to the EPERM issue -- if the attribute remains in user namespace, it should just successfully set with its original name. So the plea is not just make the EPERM go away but pls also make sure that namespace flipping is fully functional for symlinks, too.

Comment 2 Venky Shankar 2012-03-05 10:47:27 UTC
http://lxr.linux.no/#linux+v3.2.9/fs/xattr.c#L58

/*
 * In the user.* namespace, only regular files and directories can have
 * extended attributes. For sticky directories, only the owner and
 * privileged users can write attributes.
 */

Don't know why this constraint is there.

Comment 3 Csaba Henk 2012-03-05 13:14:22 UTC
Damnit, too bad.

Actually the attr(5) manpage: http://linux.die.net/man/5/attr gives a brief summary of the namespaces + policies + rationale. It's never too late to read the reference of the APIs we use! ;)

So, as of attr(5), maybe "system" should be our bet instead of "user". Do you see any issue with that?

Comment 4 Venky Shankar 2012-03-06 06:07:36 UTC
Yeh, security.* and system.* are not blocked by VFS; so that should be good for us. Best bet as you said would be system.* since security.* would look some security related attribute.

Comment 5 Anand Avati 2012-03-08 07:05:43 UTC
CHANGE: http://review.gluster.com/2890 (cleanup and fix xattr namespace flip) merged in master by Vijay Bellur (vijay)

Comment 6 Vijaykumar Koppad 2012-06-01 08:05:41 UTC
This bug is still there in 3.3.0qa45

Comment 7 Amar Tumballi 2013-02-20 06:36:57 UTC
Vijaykumar, can you please check this on 3.4.0qaN releases?