From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: luciano.rocha@booking.com, git@vger.kernel.org, peff@peff.net
Subject: Re: [PATCH 1/1] freshen_file(): use NULL `times' for implicit current-time
Date: Wed, 15 Apr 2020 23:48:47 +0000 [thread overview]
Message-ID: <20200415234847.GI2751707@camp.crustytoothpaste.net> (raw)
In-Reply-To: <xmqq4ktk5t4h.fsf@gitster.c.googlers.com>
[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]
On 2020-04-15 at 21:36:14, Junio C Hamano wrote:
> luciano.rocha@booking.com writes:
>
> > Update freshen_file() to use a NULL `times', semantically equivalent to
> > the currently setup, with an explicit `actime' and `modtime' set to the
> > "current time", but with the advantage that it works with other files
> > not owned by the current user.
> >
> > Fixes an issue on shared repos with a split index, where eventually a
> > user's operation creates a shared index, and another user will later do
> > an operation that will try to update its freshness, but will instead
> > raise a warning:
> > $ git status
> > warning: could not freshen shared index '.git/sharedindex.bd736fa10e0519593fefdb2aec253534470865b2'
>
> A couple of questions:
>
> - Does utime(fn, NULL) work for any non-owner user, or does the
> user need to have write access to it?
The Linux man page says the following:
Changing timestamps is permitted when: either the process has
appropriate privileges, or the effective user ID equals the user ID of
the file, or times is NULL and the process has write permission for
the file.
So the answer is the user needs to have write access with utime(fn,
NULL), but the same EUID (or root) with a specific time. I believe this
behavior is because it doesn't make sense to restrict the operation
which uses the current time since a user with write permissions could
just run open(2) and write(2) instead with the same effect, just less
efficiently.
(We've discussed this on the list before, but "appropriate privileges"
is POSIX-speak for "root access" or the equivalent in an alternate
system, such as capabilities.)
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2020-04-15 23:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-14 14:27 [PATCH 1/1] freshen_file(): use NULL `times' for implicit current-time luciano.rocha
2020-04-14 19:55 ` Jeff King
2020-04-15 9:09 ` [External] " luciano.rocha
2020-04-15 16:05 ` Jeff King
2020-04-15 17:30 ` Junio C Hamano
2020-04-15 21:36 ` Junio C Hamano
2020-04-15 23:48 ` brian m. carlson [this message]
2020-04-16 1:02 ` Junio C Hamano
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=20200415234847.GI2751707@camp.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=luciano.rocha@booking.com \
--cc=peff@peff.net \
/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).