File mode

[Matthieu Moy]

jeffpc at josefsipek.net (Josef "Jeff" Sipek) writes:

> On Sat, Sep 09, 2006 at 09:57:56AM -0500, Matt Mackall wrote:
>> Even git only uses one bit of the mode it stores.
>
> Hrm. You are right.
>
>> With good reason - there are security concerns. Instead we follow the
>> normal UNIX umask conventions.
>  
> Alright.

Indeed, GNU Arch stores more that the 'x' bit. I've never found it
useful for my own use, but it has many times given me troubles.

Regarding _your_ permissions, the cases where you want to prevent
yourself from reading/writting on a file are rare. Regarding the
"group" part, it's 100% site-specific, since people will have
different groups on different hosts where they checkout, and for the
"other" part, the policy is also site-specific. If you develop free
software or if you trust other users, you'll want to give the "read"
permission to everybody. But having someone who don't trust other
users and someone who does working together with a RCS that sets those
bits is a mess.

And yes, the security risk is there. I already found some
world-writable files in a GNU Arch project.

That said, it can be useful on 0.01% (?) of cases, and I'll take once
more the example of GNU Arch: a user wanted to version-control / on
several machines (not just for backup, but also to merge changes from
a machine to another), and an option has been added to track all the
bits (sticky bit, suid, ...), the group name and all, but obviously,
it's disabled by default. I'm not sure this has actually been used by
anyone finally.

> In what way? The only thing I can think of is accidental creation of cycles
> in the working dir. (I know someone who messed his SVN repo up with a
> symlink to '.'.) But if care is taken for hg to never follow links
> everything should be fine.

If you follow symbolic links, you have another problem which is that a
symlink can point outside your tree. Security concern here too:
things like merging could then write outside the tree (and therefore
to an arbitrary location).

Tracking the target of symlinks is OTOH something I find useful, and
seems not too problematic. I'm versionning my ~/bin/ with bzr, it
contains mostly a few home-made scripts and some symlinks (typically
to chose between several versions of a software on the system), and
it's convenient to manage multiple machines.

-- 
Matthieu