From: Junio C Hamano <gitster@pobox.com>
To: Julien Moutinho <julm+git@sourcephile.fr>
Cc: git@vger.kernel.org, Eric Wong <e@80x24.org>
Subject: Re: FORCE_DIR_SET_GID denied inside nix's build sandbox
Date: Tue, 25 Oct 2022 09:54:59 -0700 [thread overview]
Message-ID: <xmqq7d0nonbw.fsf@gitster.g> (raw)
In-Reply-To: <20221025163024.uutqv7w24yi4eo5i@sourcephile.fr> (Julien Moutinho's message of "Tue, 25 Oct 2022 18:30:24 +0200")
Julien Moutinho <julm+git@sourcephile.fr> writes:
> While running public-inbox's tests inside nix's build sandbox
> I've noticed that when core.sharedRepository is set to 0600
> git still tries in adjust_shared_perm()
> to set the g+s bit on directories.
> https://github.com/git/git/blob/1fc3c0ad407008c2f71dd9ae1241d8b75f8ef886/path.c#L901-L905
> ...
> So, on meta@public-inbox.org we were wondering whether
> git should maybe strip S_ISGID and retry to chmod() if it hits EPERM?
But that can leave the repository unusable when the files and
directories has to be owned by the same group as its containing
directory.
It does sound like we are bit too aggressive when setting the g+s
bit.
Is g+s only necessary if the directory is group writable? Not
necessarily. When I am the only writer (and owner) with memberships
in multiple groups, a shared repository that I intend to give read
(but not write) permission bit to members of a specific group must
be owned by that group, and setting g+s is how we ensure it. So it
is insufficient to give when new_mode says it is group writable. We
also should do g+s if it is readable by the group.
But if you use 0600, then the group ownership should not matter, so
/* Copy read bits to execute bits */
new_mode |= (new_mode & 0444) >> 2;
if (new_mode & 060)
new_mode |= FORCE_DIR_SET_GID;
might be what you want?
next prev parent reply other threads:[~2022-10-25 16:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 16:30 FORCE_DIR_SET_GID denied inside nix's build sandbox Julien Moutinho
2022-10-25 16:54 ` Junio C Hamano [this message]
2022-10-25 22:40 ` Julien Moutinho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq7d0nonbw.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=julm+git@sourcephile.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).