Proposal: inherit group

[Pierre-Yves David]

On Thu, Oct 11, 2012 at 11:18:08AM +0200, Isaac Jurado wrote:
> On Thu, Oct 11, 2012 at 10:50 AM, Pierre-Yves David
> <pierre-yves.david at logilab.fr> wrote:
> > On Wed, Oct 10, 2012 at 08:57:29PM -0500, Matt Mackall wrote:
> >> Currently, Mercurial inherits file permission bits from .hg/store. This
> >> lets newly-created files in a repo on a shared filesystem get
> >> group-compatible permissions regardless of the current umask of the
> >> user.
> >>
> >> Unfortunately, the group attached to the file will not automatically be
> >> a useful one unless all the directories in .hg/store are also carefully
> >> marked g+s so that newly-created files and directories get shared with
> >> the appropriate group. This, being a bit outside Unix Permissions 101,
> >> is apparently not something most people know how to do.
> >>
> >> So it might significantly ease things if we tried to automatically copy
> >> the group from the .hg/store directory to newly created files and
> >> directories in the store.
> >
> > +1 on that. I've never seen a shared repo without this g+s bit.
> > (except broken one)
> 
> Although being neutral about this, I think requiring the g+s bit also
> serves as an explicit indicator of a shared repo.  Lifting this
> requirement could be confusing or even a security problem (when using
> careless umasks).

No, it's not an explicit indicator of a shared repo:

- setting the ownership to a shared group is an explicit indicator.

- setting the g+w group is too.

Setting the g+s bit so that the two explicite action above actually
works is just painful administration operation that most user totally
miss before blaming the tool.

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121011/d27ca3f1/attachment.pgp>