Bug 6701 - permission of attributes are not preserved
Summary: permission of attributes are not preserved
Status: NEW
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.0
Hardware: Other Solaris
: P3 minor (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-09 03:21 UTC by Enrico Cavalli
Modified: 2011-06-07 23:54 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Enrico Cavalli 2009-09-09 03:21:48 UTC
This relates to fake-super on solaris, but actually is more general because xattr are files so have ownership and permission which is not preserved by  -X (-XX)

Suppose I have this situation

root@opensolaris:~/src/rsync# runat /data/cavalli/test ls -l
total 2
-rw-rw---- 1 cavalli other  13 2009-09-08 08:14 rsync.%stat
-r--r--r-- 1 root    root   84 2009-09-08 08:14 SUNWattr_ro
-rw-r--r-- 1 root    root  408 2009-09-08 08:14 SUNWattr_rw

Then root does a rsync -XX. We end up with

-rw-rw---- 1 root root  13 2009-09-08 08:14 rsync.%stat

So that user cavalli does no longer see fake-super information in the "backup of the backup"...

In this case a quick solution could be creating the xattr with read permission for "other", but the problem is more general.

I think that -X beavhiour should be:

- for every user preserve permissions 
- for root preserve permission and ownerships

diff --git a/lib/sysxattrs.c b/lib/sysxattrs.c
index d55ee0c..c9a38cd 100644
--- a/lib/sysxattrs.c
+++ b/lib/sysxattrs.c
@@ -191,7 +191,7 @@ int sys_lsetxattr(const char *path, const char *name, const 
 {
        int attrfd;
        size_t bufpos;
-       mode_t mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP;
+       mode_t mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH;
 
        if ((attrfd = attropen(path, name, O_CREAT|O_TRUNC|O_WRONLY, mode)) < 0)
                return -1;
Comment 1 Matt McCutchen 2009-09-10 15:29:13 UTC
Is the mode and ownership all, or is there other metadata to worry about?  Do xattrs have mtimes?  Does a file have a separate set of directory-like permissions that control the creation, deletion, and renaming of its xattrs?  Can xattrs have ACLs?  Can they have their own xattrs?  :D

This is going to be fun to implement.
Comment 2 Matt McCutchen 2009-09-10 15:51:48 UTC
(In reply to comment #1)
> Is the mode and ownership all, or is there other metadata to worry about?  Do
> xattrs have mtimes?  Does a file have a separate set of directory-like
> permissions that control the creation, deletion, and renaming of its xattrs? 
> Can xattrs have ACLs?  Can they have their own xattrs?  :D

I thought I was joking, but the answer to all questions is yes!  (At least in the interface, though not on current filesystems.)

http://docs.sun.com/app/docs/doc/816-5175/fsattr-5?a=view

If rsync is going to go out on a limb and support this, maybe the best approach would be to hang an entire file list off each file that has xattrs.
Comment 3 Matt McCutchen 2011-06-07 23:54:03 UTC
In the absence of a protocol extension to carry the actual attributes, one reasonable thing rsync could do is set the permissions and ownership to emulate the Linux access control rules for user xattrs, i.e., same as the file itself except never executable.  (Rsync takes the view that the entire Solaris xattr space corresponds to the Linux user namespace; the analogy is imperfect but better than the alternatives.)