On Mon, Apr 25, 2022 at 07:05:49AM +0200, SZEDER Gábor wrote:
> On Sun, Apr 24, 2022 at 07:01:08PM -0700, Carlo Marcelo Arenas Belón wrote:
> > On Sat, Apr 23, 2022 at 04:44:57PM -0700, Junio C Hamano wrote:
> > >
> > > Actually, not quite. when "git" runs in "sudo git", the real
> > > identity has long lost
> >
> > Right, but in this specific case, the terminal is still a good indication
> > of who the user is, so the following would work.
> >
> > diff --git a/git-compat-util.h b/git-compat-util.h
> > index 58fd813bd01..5d5d91688ee 100644
> > --- a/git-compat-util.h
> > +++ b/git-compat-util.h
> > @@ -442,6 +442,11 @@ static inline int is_path_owned_by_current_uid(const char *path)
> > struct stat st;
> > if (lstat(path, &st))
> > return 0;
> > + if (isatty(1)) {
> > + struct stat ttyst;
> > + if (!stat(ttyname(1), &ttyst))
> > + return st.st_uid == ttyst.st_uid;
> > + }
> > return st.st_uid == geteuid();
> > }
>
> Our 'GIT-VERSION-GEN' runs 'var=$(git describe ...)', so standard
> output is not a terminal during 'sudo make install'
didn't realize the orginal report was coming from `sudo make install`
in git's own repository, but even that worked for me.
when I meant the original case I went with an artificial test where
I run :
$ mkdir -p r/t
$ sudo chown root r
$ cd r/t
$ git init
$ sudo git status
and I get no error, unlike the original version of the code.
of course, part of the "extra work needed" is to figure out if stdout
is the best place to look at, I chose it just because that is the
unoficial way to signal in our code that we are running interactively.
note that usually unless a pipe is involved or nohup is used, the tty
is still attached to your process.
Carlo
