DO NOT REPLY [Bug 3277] [Feature req] "I couldn't do something you asked" warning

bugzilla-daemon at dp3.samba.org bugzilla-daemon at dp3.samba.org
Sun Jan 29 17:57:11 GMT 2006


https://bugzilla.samba.org/show_bug.cgi?id=3277


hashproduct at verizon.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hashproduct at verizon.net




------- Comment #5 from hashproduct at verizon.net  2006-01-29 10:57 MST -------
I like the idea of --super and --no-super overriding rsync's own detection of
whether it is running as root.  But at the risk of annoying Wayne, I still
think rsync's behavior with respect to file security settings should be
reconsidered.

Right now, rsync offers two behaviors when -a is given:
    (1) Preserve permissions but not ownership or devices.  Preserve groups to
        which the user running rsync belongs.
    (2) Preserve permissions, owners, groups, and devices, producing an error
        every time it is not possible to do so.
Rsync currently chooses #1 or #2 based on whether it is root, and this choice
can now be overridden with --super or --no-super.

Many people (including me and Lenny) use rsync for backups, and the stricter
checking of #2 is obviously preferred for backups.  Presumably #1 is for a
"normal user for a normal copy", and indeed, I use rsync as a normal user for a
normal copy several times a day.  I definitely want to recurse and preserve
links, modtimes, and (if there are any) special files.

-a would be perfect except for one thing: I often copy files between areas with
different "ambient" permissions (which I have configured with default ACLs). 
When I copy files from my home directory (700) to my Web site (755) or to a
shared group workspace (2770), I expect them to take on permissions appropriate
for the destination!  When they don't, I fix them manually with chmod; if I
forget to do so, annoyance can result.

For example, visitors to my school's Web site encountered a 403 Forbidden error
on a PDF file, which surprised me because I had personally configured the site
with a default ACL of 775.  It turned out that another administrator had
uploaded the file, which for some reason had come out of the PDF creator with
600 permissions, using a program that preserved permissions.  I think rsync can
do better.

I want this behavior:
    (3) Preserve everything not security related, but use appropriate
        security settings (permissions, group) for the destination.
-a incorrectly second-guesses my intent; even -p ANDs with source permissions. 
I have been using the following incantation, which I named cp2:
        rsync -rltE --chmod=ugo=rwX ...
(-E is my custom rsync's --executability; ignore it throughout my comment
unless the official rsync adopts this feature.)

I guess I could make a personal popt alias for -rltE --chmod=ugo=rwX, but if -a
--super is to have an official alias, could I please have one for behavior #3? 
I venture to say that it is at least as useful as #1.  In fact, would anyone
object if the non-root meaning of -a changed to behavior #3?


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.


More information about the rsync mailing list