bzr does not store permissions

This is simply because bzr does not version anything but the executable bit. And in the short term, there is no plans to version more than that.

It is *possible* to do more, but past experience with other systems (Arch) means that it usually causes more problems than not when versioning source code. (If your mask is not my mask, then commits tend to ping pong back and forth).

For versioning $HOME or /etc, it *is* useful to version strict permissions, and possibly even user and group. But for most source code, it is not useful.

So for now, bzr is focused on versioning source code. Versioning detailed file modes and user/group info should be possible without too much extra effort, and if someone wants to write a plugin to do so, we are willing to help a little bit, and give pointers as to what it would take.

> bzr does not version anything but the executable bit

Thanks for pointing this out to me. Next time I'm going to RTFM first, though. It's in the FAQ... <hides/>

> So for now, bzr is focused on versioning source code.

That's a pity, but I guess file permissions are an implementation detail of the underlying file system anyway, and bzr cannot reasonably be concerned about permission metadata in a portable way (Win32, SE Linux, RSBAC...).

In retrospect, it seems like bad idea to include my keys in that branch anyway. Now I'll just have to find a way to "unpull" that merge without completely starting the branch over...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> This is simply because bzr does not version anything but the executable
> bit. And in the short term, there is no plans to version more than that.

To expand a bit, new files are created with your umask, except for the
execute bit. When files are modified, whatever permissions they had on
disk are preserved.

The .gaim files you have after the merge are *new* files that bzr has no
reason to connect to the files that were previously under .gaim. The
.gaim.moved files are the files you previously had there.

It really has nothing to do with conflicts. Name the two directories
different things, and do a merge, and you'll get the same results.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFO/su0F+nu1YWqI0RAvVXAJ4/tI2md6WXEKSAZiEKMj0ax8gpCgCfYPss
C6CFjuGXWMoegxx8VbgqLuo=
=bAMn
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonathan Knowles wrote:
> ** Description changed:
> I'd consider this a security vulnerability, but am going to wait for
> feedback before tagging it as such. Versions used: Debian bzr-0.10-1 on
> ws1, Ubuntu bzr-0.8.2-1ubuntu3 on ws2. If you need further info, I'll do
> my best to provide it.

Bazaar is a software development tool first and foremost. We don't
consider permissions other than the execute bit to be relevant to
software development. Supporting them would add complexity and take
resources away from other activities.

You may certainly version config files using Bazaar, but you are not
using it as intended.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGf9ad0F+nu1YWqI0RAhdRAJ9mWORWoXgWWA+Z+4Xfd6u1O69vLwCfcTJc
5z/jOByVOKluEwvWcSqx0Fs=
=5w4v
-----END PGP SIGNATURE-----

Yes, bzr wouldn't bend to my intention ;) That's why I've set the »home directory as repository« idea aside for the time being. Do you have any suggestions as to which VCS would be more appropriate for this particular use case? I don't know about any which actively supports permissions.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Werner wrote:
> Yes, bzr wouldn't bend to my intention ;) That's why I've set the »home
> directory as repository« idea aside for the time being. Do you have any
> suggestions as to which VCS would be more appropriate for this
> particular use case? I don't know about any which actively supports
> permissions.

Gnu Arch stores permissions. I don't know if I'd want to use it, though.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGf+AV0F+nu1YWqI0RAojxAJ0e7fFwiLLVqu2oNeFiyZTUhW+3mACeMoJ0
b3uEEC0JtG9FLY4oAk+wZgc=
=ikBL
-----END PGP SIGNATURE-----

I'll just add my own opinion that versioning /etc files or dot-files is a perfectly legitimate use case for a version control system, and a dvcs should be expecially well suited to that. I currently version my own such files under Subversion, while the Python project has started versioning some of its machine /etc files under Bazaar.

That's not to say I'm advocating version permissions or not. It would be helpful, but in my experience, that's not the only problem with version config files. You often have subtle differences from machine to machine that a version control system doesn't really provide a way to handle (nor should it). Subversion for example also has problems with getting /etc/ files all versioned nicely without hacking its local meta files. And most applications are not prepared to have their config files handled by a version control system, e.g. item sort orders not being stable, or constantly changing values such as last-touched dates mixed in.

It's a great idea, but I agree that bzr has more important things to do. If the OP does develop a plugin, please let us know!

I was just thinking about using bazaar for configuration files, and think versioning permissions are something that would be worthwhile. One way for implementing the saving of permissions might be to only save/update/restore them when specifying '--with-perms' or similar. The default behavior could stay as it is now, and therefore would not break existing configurations or introduce all the umask issues as described above when dealing with source code. My two cents.

People are already trying to use bzr to backup system files. And they are moving away to Git, SVN or some ad-hoc solutions.

Have a look at these Ubuntu blueprints:

https://blueprints.launchpad.net/ubuntu/+spec/etc-in-svn
https://wiki.ubuntu.com/VersionControlledEtc

https://blueprints.launchpad.net/ubuntu/+spec/home-user-backup

They both require the use of a VCS (or are reinventing a VCS) to store generic system and user files, not just source code.

This issue, if I have understood it correctly, is causing trouble on a project I am working on. All the time. We're team of ~five building a web application, each of us with a development branch running live on a server, available to the word via each person's public_html directory.

Alice creates a file. A server-side script. A javascript. A stylesheet. Or an image. It doesn't matter what. She changes the file permissions on this new file, allowing Apache to access it.

Bob then merges with Alice, recieving this new file. But the permissions are now incorrect. Apache can't access the file, and returns a 403 error when someone attempts to load it. There are thousands of files in our repositories, with new ones added all the time. It's impossible to keep up, so some things are randomly broken on Alice's test site; something else is broken on Bob's.

And sometimes these issues appear on production servers and noone can understand why. "It works in my tree! The code is identical!".

On Tue, 2008-07-22 at 22:17 +0000, Wilhelm J.A. wrote:
> This issue, if I have understood it correctly, is causing trouble on a
> project I am working on. All the time. We're team of ~five building a
> web application, each of us with a development branch running live on a
> server, available to the word via each person's public_html directory.

I suspect something other than bzr is the problem here.

If bzr *did* store permissions it would cause the problem you appear to
be describing (because it would be setting the owner and restricting
read access etc).

Perhaps your umask is overly restrictive?

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

i know that storing the file permissions is not needed for keeping track of source code. it even can cause some problems (see the example above mentioning two different umasks that cause permissions to change on every check-in).

some people (including me) use bazaar for things it was not originally intended for. and it does a a great job and fits nearly perfectly - expect for the fact that it does not track file permissions. right now i am using some very, very nasty code to make thinks work.

i'd like to ask the developers to include tracking of file permissions into bazaar. this would improve it's usability to e.g. track ones /etc/ or $HOME. it should be optional (because annoying in some situations) and could either track the permissions or some kind of mask combined with the umask make sure certain rights are (not) granted.

having this in the core would speed up things, make them more reliable and ensure synchronism.

what i am doing right now (breaks with bad file names (works with spaces and umlauts), is slow, and kind of anti-VCS...):
grab the file rights:

if [ "$1" ]; then
 echo `stat -c %a "$1"` \"$1\"
else
 bzr ls --versioned --null | xargs --null -n 1 "$0"
fi

save them to a file (versioned)

and reapply them:
xargs -n2 chmod -c

so +1 for making bzr store file permissions from me!

The Ubuntu package "etckeeper" uses a similar hack to version the /etc directory. It stores all non-standard file ownerships (that is, user/group != root) and non-standard permissions (mode != umask) in a versioned file /etc/.etckeeper. This file is formatted like a shellscript, which when executed will reset all ownerships and permissions to the values stored within.

This approach has the merit that it's compatible among all VCS' supported by etckeeper (bzr, git, mercurial), though it effectively keeps file metadata detached from the file it belongs to and doesn't understand keeping ancestry on renames. etckeeper has worked nicely for my machines so far, though I can imagine its permission approach could cause trouble later on.

I am reviving the idea of using version control on /etc to get a versioned view of configuration changes, mostly for servers and multi-admin environments. See draft at:

https://wiki.ubuntu.com/EtcUsingEtckeeperSpec

It might or might not use EtcKeeper, but the killer feature would be to have the owner/group/permissions information stored directly in the VCS rather than using an out-of-band hack.

It's obvious this is not a wanted feature for source code versioning, so it would be an option/plugin thing. Before I push this spec any further, how complex do you estimate it is to add that feature to bzr ? Is is something that can be implemented in the plugin framework, or would need to be added as an option to the core code ?

On Thu, 2008-11-27 at 09:45 +0000, Thierry Carrez wrote:
> Before I push this spec any further,
> how complex do you estimate it is to add that feature to bzr ? Is is
> something that can be implemented in the plugin framework, or would
> need
> to be added as an option to the core code ?

AIUI etckeeper it adds its own database, for git/bzr/hg/etc/etc for
permissions. This is entirely appropriate.

what would be good would be providing enough hooks that 'bzr st' and
other commands can show/understand changes against that permissions
database so that you can just use 'bzr commit' to do this.

You would definitely need changes to the core to do this, but they would
be cosmetic changes rather than structural - you don't need a new data
store for instance, as this would be layering on top.

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

My concern with this solution is the separation of the permission metadata store from the files/directories object they cover. For example, in case of file renaming (or swapping), which is a common case for configuration files, you'd more than probably lose permission/ownership history.

I've thought of another option that might be simpler and more reusable:

bzr could implement add a generic <meta> text field for each InventoryEntry and two hook functions (get_meta_from_file/dir/link and set_meta_to_file/dir/link) to get this meta info (whatever it might be) and set it back to the real file/dir/link objects. For all functions it considers the files identical if the <meta> info (if any) matches.

This has been discussed before, see [1] or [2], as a way to extend bzr appropriateness for weird applications without going for a specific, non-portable set (owner/perms) or impacting normal bzr usage.

[1] http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/1245/focus=1248
[2] http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/1293/focus=1299

This solution looks elegant but might imply deeper structural changes (addition of a tag in InventoryEntry) ?

On Mon, 2008-12-01 at 09:54 +0000, Thierry Carrez wrote:

> My concern with this solution is the separation of the permission
> metadata store from the files/directories object they cover. For
> example, in case of file renaming (or swapping), which is a common
> case
> for configuration files, you'd more than probably lose
> permission/ownership history.

The most immediate way to address that concern is to key the separate
metadata by fileid, rather than by path. Alternatively we can call into
plugin code on renames so that it can update the separate store.

At this point I'd really like to avoid depending on changes down at the
deep inventory level: depending on such a facility would make this a
large change rather than a small change.

-Rob

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

I agree there is no need to put the extra metadata in the /same/ data repository, as long as we can reliably link information between the two. I supposed it would be simpler to extend the current inventory than to implement a separate parallel one, but you know bzr better than I do :)

I still think it would be valuable to implement this in a reusable way : to merge the two proposals in one, how feasible would it be to implement a separate, generic metadata store that gets used if you provide the corresponding hook functions :
- get the metadata information from a file/dir/link
- set the metadata information back to a file/dir/link
- represent differences in metadata in a textual form
- ...

Changing how inventories are stored, or adding another store for extra information requires a format bump and is something that only newer clients will be able to understand. (They have to look at one *more* location to find what they need.)

Adding a special file to the tree such as ".fileproperties" is just another versioned file. Some clients may or may not understand it, but all of them would transmit it and preserve it.

Arguably that is a good or bad thing. Failing to apply the properties could lead to a security hole (accidentally allowing your private key to be world-readable, for example.)

We have discussed allowing arbitrary per-file key-value dictionaries. Robert has genuine concern that it is a way to get yourself into trouble. Once you start having generic access to critical values, you start running into problems maintaining invariants. (Someone can poke in a new value for svn:eol without updating the file, for example.)