Bug 6197 - Perms/owner/group modifiers for "show" filters
Summary: Perms/owner/group modifiers for "show" filters
Status: ASSIGNED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.0
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-18 23:38 UTC by Matt McCutchen
Modified: 2009-05-23 15:28 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 Matt McCutchen 2009-03-18 23:38:37 UTC
Add modifiers for "show" filters that affect the file-list attributes of matching files.  I propose this syntax:

- p(CHMOD-TWEAKS) : apply the CHMOD-TWEAKS like the --chmod option (overloaded with "perishable")
- o(USER) : set the user owner to USER
- g(GROUP) : set the group owner to GROUP

Issues to be considered:
- Interaction with --chmod, --chown, --usermap, --groupmap options
- Per-dir merge files become more powerful, so copying from an untrusted source with a per-dir merge rule becomes more dangerous.  Do we care?

I am hoping to use this enhancement in the build process of my Web site.  I have all the content in a "build tree" with makefiles to generate pages from a template.  Then I call rsync with a bunch of filters to mirror a subset of the build tree to the Web server's document root.  Different areas of the document root need different permissions: almost everything is 755/644, but as one notable exception, the /private dir is 711.  I applied the desired permissions manually, but I want to make sure they don't get messed up.  With this enhancement, I could add p(...) modifiers to the rsync filters to have it apply the permissions automatically on every build.  For example:

rsync -rltp --filter='Sp(u=rwX,go=X) /private' --filter='Sp(u=rwX,go=rX) *' \
    build/ /var/www/html/

More generally, this enhancement could be used to implement any "make install"-like step with a single rsync run, which I feel would be a significant advance over install(1).  With --delete-missing-args, "make uninstall" could probably be implemented as well.
Comment 1 Matt McCutchen 2009-03-20 01:14:01 UTC
I put a draft implementation in branch wip/filter-attrs of my repository.  It works in some simple tests, but it needs some polishing and documentation before it could go into the main rsync.
Comment 2 Matt McCutchen 2009-05-04 22:14:08 UTC
I have polished the implementation a bit and split it into well-described commits.  Wayne, please consider this for the main rsync or a maintained patch.

Note: I found that I couldn't actually overload the permissions modifier with the perishable "p" as proposed in comment #0 because a merge rule needs to be able to specify a default for both modifiers.  Thus, I used "m" instead.
Comment 3 Wayne Davison 2009-05-07 16:18:05 UTC
Thanks for the patch -- it looks good.  I've worked a bit on getting it integrated into 3.1.0dev, and will try to finish it off soon.
Comment 4 Wayne Davison 2009-05-23 15:28:17 UTC
Matt:  I've added your various foundational patches plus some changes of my own, and then regenerated your final commit as a patch:

http://gitweb.samba.org/?p=rsync.git/patches.git;a=history;f=filter-attribute-mods.diff

I'm thinking that, before I apply this patch, I would like some way to allow users to avoid unintended chown/chmod items in the merge files.  One possible solution:

Add a trust (t) modifier for the merge-file filter rules that will mark the file as trusted.  Any chown/chmod rules that are found in a non-trusted file would output a warning and skip the rule.  Any merge-file rule (per-dir or not) defaults to having untrusted rules unless it is marked as trusted (even if it comes from a trusted source).

All command-line filter options would get processed with the internal "trusted-source" flag, so direct-on-the-command-line chown/chmod filter rules would all work.

Thoughts?