Bazaar

Bug #50568
Comment #19

Comment 19 for bug 50568

Revision history for this message

Deni Bertovic (denibertovic) wrote on 2011-08-25:

#19

I've found out some new Information and possible work arounds.

bzr over sftp and bzr+ssh have the same fault as far as I have tested. Meaning that they both disregard the default umask set up in /etc/profile during the *INITIAL* push to a remote repo. Just so there is no confusion and that we are all clear on this, this only happens during the initial push, meaning the folder is not on the the remote host yet. Bzr creates it....with the wrong permissions :). After bzr created the remote folder and I ssh to the remote machine, do a manual chmod g+w everything works fine after that and all leading pushes (from OTHER users) to that repo work just fine.

Now, the reason bzr ssh and sftp ignore the /etc/profile default umask setting is because AIUI no bash shell is executed and therefore the /etc/profile file is not even read.

There is a way to correct this for sftp. Edit sshd_config change the part with sftp to: 'Subsystem sftp /usr/lib/openssh/sftp-server -u 007' (or the desired umask..in my case it's 007 so the dev group have write permissions to the repos).

This does NOT work for bzr+ssh.....or scp for that matter. To make ssh affected you have to change the pam settings in /etc/pam.d/sshd and add the line "session optional pam_umask.so umask=007". So this affects sftp, scp and ssh. Note that for ssh to use pam it needs to have the UsePam directive set to yes in /etc/ssh/ssd_config file.

Now everything works fine. Or does it?!?! We worked around the issue of bzr messging up the permissions on an initial push but now we are stuck with the umask 007 set for all users on the system. Meaning if you create a file in your home directory it will be readable and writeable by the group your username belongs to. Not the best solution in the world.

Also, it helps to know that the user specific settings override all this. Meaning if a user sets the umask to 022 in his ~/.profile or .bashrc it will override the global settings. Again, these script will be called only if a bash shell is executed.

And that's it. Hope this information helps someone. Atleast until this issue is fixed.

I've found out some new Information and possible work arounds.

bzr over sftp and bzr+ssh have the same fault as far as I have tested. Meaning that they both disregard the default umask set up in /etc/profile during the *INITIAL* push to a remote repo. Just so there is no confusion and that we are all clear on this, this only happens during the initial push, meaning the folder is not on the the remote host yet. Bzr creates it....with the wrong permissions :). After bzr created the remote folder  and I ssh to the remote machine, do a manual chmod g+w everything works fine after that and all leading pushes (from OTHER users) to that repo work just fine.

Now, the reason bzr ssh and sftp ignore the /etc/profile default umask setting is because AIUI no bash shell is executed and therefore the /etc/profile file is not even read.

This does NOT work for bzr+ssh.....or scp for that matter. To make ssh affected you have to change the pam settings in /etc/pam.d/sshd and add the line "session    optional     pam_umask.so umask=007". So this affects sftp, scp and ssh. Note that for ssh to use pam it needs to have the UsePam directive set to yes in /etc/ssh/ssd_config file.

Now everything works fine. Or does it?!?! We worked around the issue of bzr messging up the permissions on  an initial push but now we are stuck with the umask 007 set for all users on the system. Meaning if you create a file in your home directory it will be readable and writeable by the group your username belongs to. Not the best solution in the world.

And that's it. Hope this information helps someone. Atleast until this issue is fixed.