From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: git <git@vger.kernel.org>
Subject: Re: [RFH] Git and filesystem ACLs: problem with 'git gc'
Date: Wed, 13 Jan 2010 15:56:58 +0100 [thread overview]
Message-ID: <vpqeiludpdx.fsf@bauges.imag.fr> (raw)
In-Reply-To: <vpqy6k38lzd.fsf@bauges.imag.fr> (Matthieu Moy's message of "Tue\, 12 Jan 2010 14\:57\:10 +0100")
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> I investigated a bit, and the problem seems to come from mkstemp,
> which is used by write_pack_file to create the temporary file: files
> created by mkstemp get an ACL umask of ---.
>
> Is it really a good idea to use mkstemp? We're inside
> .git/object/pack, for which the user is supposed to have already set
> correct permissions, so shouldn't we just create a random file name
> and then use a plain open(...) to create the file, leaving the umask
> do its job to control the permissions?
Digging a bit further, I noticed that _object_ creation was doing a
set_shared_perm(filename, (S_IFREG|0444))
thus ignoring the umask, and setting r--r--r-- for all objects, while
_pack_ creation does roughly (in write_pack_file()) :
mode_t mode = umask(0);
mode = 0444 & ~mode;
adjust_perm(pack_tmp_name, mode)
Thus setting the permissions to r--X--X-- where X is defined by the
umask. Is there any reason for this difference? I'd say we can rely on
the containing directory's permissions, and do for pack what Git
already does for objects.
[ On a side note, I don't understand what the S_IFREG is doing in the
call to set_shared_perm. It's passed to chmod, while S_IFREG is only
documented in the manpage for stat() ... ]
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
prev parent reply other threads:[~2010-01-13 15:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-12 13:57 [RFH] Git and filesystem ACLs: problem with 'git gc' Matthieu Moy
2010-01-13 14:56 ` Matthieu Moy [this message]
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=vpqeiludpdx.fsf@bauges.imag.fr \
--to=matthieu.moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
/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