file upload should not assume 0664 permissions

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

-Rob

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/>

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>.

>>>>> "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

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.

@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 ?

@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 )

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

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.

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