file upload should not assume 0664 permissions

[James]

Hi

I've noticed that on upload, the file permissions are being set as group writable e.g -rw-rw-r-- (0664). I tracked down this ( I think) in __init__.py, line 119 (note directories are also given rwx permissions for group).

The problem is that I'm dealing with a dumb server (out of my control) that is set up to disallow running of PHP files that are group writable. I have to log in and update the permissions of each file that is uploaded, post bzr upload, which is a pain if I upload 100's of files :(

<pre>
    def upload_file(self, relpath, id, mode=None):
        if mode is None:
            if self.tree.is_executable(id):
                mode = 0775
            else:
                mode = 0664
        if not self.quiet:
            self.outf.write('Uploading %s\n' % relpath)
        self.to_transport.put_bytes(relpath, self.tree.get_file_text(id), mode)
</pre>

Output of bzr ann __init__.py:
<pre>
46 v.ladeu | def upload_file(self, relpath, id, mode=None):
               | if mode is None:
               | if self.tree.is_executable(id):
               | mode = 0775
               | else:
               | mode = 0664
34 argenti | if not self.quiet:
               | self.outf.write('Uploading %s\n' % relpath)
46 v.ladeu | self.to_transport.put_bytes(relpath, self.tree.get_file_text(id), mode)
</pre>

I notice that there is a mode arg, defaulting to None, which looks to be the default for the upload from where i can see this method being called. There is no mode help in "bzr help upload" so I'm not sure who to force the mode I want.

This seems to be a recent change as the upload was working ok before the last couple of pulls I did to get the latest code.

A solution would be to set the same permissions as the local file. e.g if my local file is -rw-r--r-- then set "mode = 0644"

Here is what I did (on a currently bzr-upload enabled directory)

touch test.php
ls -l test.php
-rw-r--r-- 1 me me 10 2008-10-14 12:07 test.php

//current directory
ls -la .
drwxr-xr-x 16 me me 12288 2008-10-14 12:07 .
drwxr-xr-x 29 me me 4096 2008-10-13 12:53 ..

bzr add test.php
bzr commit -m "test file permission bug" test.php

bzr upload ftp://user@path
Uploading test.php

//check permissions on remote side with FTP client for file test.php
result: -rw-rw-r--

expected result: -rw-r--r--

I manually changed 0664 to 0644 at line 119 and it worked as I expect (but that's obviously not the solution for every case).

Thanks!
James

[Robert Collins (lifeless)]

You can set your umask to filter out group and world bits if you like.
bzr shouldn't override that.

-Rob

[Martin Pool (mbp)]

On Tue, Oct 14, 2008 at 1:00 PM, Robert Collins
<email address hidden> wrote:
> You can set your umask to filter out group and world bits if you like.
> bzr shouldn't override that.

But he may not have any practical way to set a umask when connecting over ftp.

--
Martin <http://launchpad.net/~mbp/>

[Robert Collins (lifeless)]

On Tue, 2008-10-14 at 02:27 +0000, Martin Pool wrote:
> On Tue, Oct 14, 2008 at 1:00 PM, Robert Collins
> <email address hidden> wrote:
> > You can set your umask to filter out group and world bits if you like.
> > bzr shouldn't override that.
>
> But he may not have any practical way to set a umask when connecting
> over ftp.

urg.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Vincent Ladeuil (vila)]

>>>>> "James" == James Ellis writes:

    James> Public bug reported:
    James> Hi

    James> I've noticed that on upload, the file permissions are
    James> being set as group writable e.g -rw-rw-r-- (0664). I
    James> tracked down this ( I think) in __init__.py, line 119
    James> (note directories are also given rwx permissions for
    James> group).

    James> The problem is that I'm dealing with a dumb server
    James> (out of my control) that is set up to disallow running
    James> of PHP files that are group writable.

Haaa, thanks, this helps determine the relevant use cases.

    James> I have to log in and update the permissions of each
    James> file that is uploaded, post bzr upload, which is a
    James> pain if I upload 100's of files :(

Sorry :(

    James> <pre>
    James> def upload_file(self, relpath, id, mode=None):
    James> if mode is None:
    James> if self.tree.is_executable(id):
    James> mode = 0775
    James> else:
    James> mode = 0664
    James> if not self.quiet:
    James> self.outf.write('Uploading %s\n' % relpath)
    James> self.to_transport.put_bytes(relpath, self.tree.get_file_text(id), mode)
    James> </pre>

<snip/>

    James> I notice that there is a mode arg, defaulting to None,
    James> which looks to be the default for the upload from
    James> where i can see this method being called. There is no
    James> mode help in "bzr help upload" so I'm not sure who to
    James> force the mode I want.

This place should be fine, this was the starting point to
implement user-controlled chmod bits handling, which get
interrupted for various reasons, the main one being that I wanted
to be able to test easily against several ftp servers.

    James> This seems to be a recent change as the upload was
    James> working ok before the last couple of pulls I did to
    James> get the latest code.

Both bzr and bzr-upload have changed, in the good direction,
sorry that you get trapped mid-way :-/

    James> A solution would be to set the same permissions as the local file. e.g
    James> if my local file is -rw-r--r-- then set "mode = 0644"

    James> Here is what I did (on a currently bzr-upload enabled
    James> directory)

Buggy as specified so far :-/

<snip/>

    James> I manually changed 0664 to 0644 at line 119 and it
    James> worked as I expect (but that's obviously not the
    James> solution for every case).

If it works for you, keep it like that. I'll make sure to have a
transition path for you when the chmod bits handling is
implemented.

The idea being to replicate the chmod bits on the current working
tree (but since bzr-upload uses a revision tree, care should be
taken to avoid mismatches). An intermediate solution will be to
use configuration variables for default values (so that you could
have specified the relevant values instead of patching the code).

Status: confirmed
Importance: high

[FabriceH (fabrice-fabriceh)]

I have the same problem.
My Server use SuPhp, an'd suphp say that a php file don't have to be group writable. (for security reason...)

Rob wrote :
>You can set your umask to filter out group and world bits if you like.
>bzr shouldn't override that.

I can administer my server, it use proftpd, I set Umask from 002 to 022, and... upload always make it group writable.
The Umask change, change the way it work with a manual ftp.

It could be great if we can set the mask as an option of bzr upload.

[James (james-ellis-gmail)]

@FabriceH

If you administer your server, wouldn't it be better/easier for you to install bazaar on the remote end and use bzr's built in commands "send","push" etc etc to make local branch changes available for merging into remote branches ?

[FabriceH (fabrice-fabriceh)]

@James
Yes... I have to do that.. Just have some problems with Gentoo packages.
For the moment I use bzr upload.
Next I will see with the pushAndUpdate plugin
( https://launchpad.net/bzr-push-and-update - http://bazaar-vcs.org/BazaarForWebDevs )

[James (james-ellis-gmail)]

Hi Fabrice

Hmm that's no good - I'm not much help on Gentoo unfortunately. That tutorial is interesting but I found bzr push way too slow for large branches (I think it uploads the entire branch to the remote server ?).

I use bzr send instead to create a patch file, that only contains branch changes, on the remote server. As bzr send doesn't support saving directives to remote paths (https://bugs.launchpad.net/bzr/+bug/221021) the patch file is uploaded using a pipe that cat's the file into the remote location:

//cd into local branch (made with bzr branch sftp://me@server/path/to/remote/branch)
//hack away and commit
$ bzr send -v -o - sftp://me@server/path/to/remote/branch | ssh me@server "cat >/path/to/directives/my-directive.patch"

Obviously having your public ssh key on the remote server helps with password prompting.

With this in place, I have a directive stored on the remote server, and we have a history of all directives applied to the remote branches. Our patch manager can review the directives prior to them being merged into production code and reject that ones that contain incorrect/invalid code. Hope that helps ?

Cheers
James

[Jeremy Visser (jeremy-visser)]

This bug has been opened nearly two years now. This bug affects me too — as with the O.P., the host I'm trying to upload to does not allow executing of PHP files with group write permissions.

[Callum Macdonald (chmac)]

Any progress on this some 4 years after it was reported?