rsync default handling of permissions

[Dave Dykstra]

On Fri, Feb 15, 2002 at 12:29:36PM +0100, Stefan Nehlsen wrote:
> On Fri, Feb 15, 2002 at 09:25:05AM +1300, Jason Haar wrote:
> > This is a "me too". We've just been stung with that too. 
> 
> I think rsync is trying to do things like rcp does:

I see comments in the code where "!preserve_perms" is used that it's trying
to behave like GNU cp.


> Use the permissions of the source file and apply the umask if -p is not
> set.
> 
> This makes sense if you use it in an closed environment with
> a centralized user base (nis, nis+, ldap ...) and useful set umasks.
> 
> permissions of unknown user and groups are useless.
> 
> access to rsyncd is typical anonymous or based on it's own user base
> ( auth users / secrets file in rsyncd.conf ) and so you don't need
> and don't want this behaviour.
> 
> > "rsync -r file remote::module/" appears to mean that the remote copy of
> > "file" indeed ends up with the perms assosiated with the umask of the rsync
> > daemon (as it should). However "rsync -r dir remote::module/" appears to
> > still transmit the permissions of the dir..
> > 
> > In fact, this brings up another issue. What if the rsync server
> > administrator wants to control permissions? What about a new config option
> > "umask = 0770" for instance? That way, irrespective of what options are used
> > by the client, the server controls the permissions; explicitly ensuring the
> > permissions are always set to that value (setting the umask before starting
> > rsync doesn't do the same thing, as this should be settable at the module
> > level). 
> 
> like samba is doing it
> 
> > At the moment doesn't there seem to be a bit too much relying on the client
> > to "do the right thing"?
> 
> If cp, rcp or scp is used it is easy to put permissions right
> 
>   chgrp -R test <dir>; chmod -R ug+rwX,o-rwx <dir> ; find <dir> -type d -print | xargs chmod g+s
> 
> will do the job, but it also mess up the modification times.
> 
> 
> rsync should do this right by itself.


The main issue for you is that the setgid bit is not being inherited from
parent directories when not using the -p option, right?  I agree that that
would make sense.  I suggest that you submit a patch.

- Dave Dykstra