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)
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.
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.
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?
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.
CHANGE: http://review.gluster.com/2890 (cleanup and fix xattr namespace flip) merged in master by Vijay Bellur (vijay)
This bug is still there in 3.3.0qa45
Vijaykumar, can you please check this on 3.4.0qaN releases?