rsync pull disregards my umask, why?

Solution 1:

I incorrectly assumed that an rsync push/pull without the -p flag would work similar to a git push/pull, and that new files would have full permissions minus the umask.

However, even without the -p flag, rsync still preserves the source file's permissions. The -p flag merely instructs rsync to (attempt to) ignore the receiver's umask.

As per man rsync:

New files get their "normal" permission bits set to the source file's permissions masked with the receiving end's umask setting, and their special permission bits disabled except in the case where a new directory inherits a setgid bit from its parent directory.

Better yet, there's a simple suggestion for how to create a flag that ignores source permissions:

To give new files the destination-default permissions (while leaving existing files unchanged), make sure that the --perms option is off and use --chmod=ugo=rwX (which ensures that all non-masked bits get enabled). If you'd care to make this latter behavior easier to type, you could define a popt alias for it, such as putting this line in the file ~/.popt (this defines the -s option, and includes --no-g to use the default group of the destination dir):

rsync alias -s --no-p --no-g --chmod=ugo=rwX

You could then use this new option in a command such as this one:

rsync -asv src/ dest/

(Caveat: make sure that -a does not follow -s, or it will re-enable the --no-* options.)

I guess I'll be doing this!

Solution 2:

I think the setgid is confusing things. Look at the -p option in the rsync man page.

Solution 3:

What is the permissions set in the original?

The umask is a filter not a setting. On other words it limits the permission bits that can be set for files (and directories). It doesn't force or require that any permissions get set, only that certain bits cannot be set.

If you need group write to be set, you may need to run chmod after the rsync.