Re: git-daemon doesn't work as expected in v2.45.1 and friends

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Reverting f4aa8c8b may not be easy to do mechanically, as it
> introduces the die_upon_dubious_ownership(), but 1204e1a8 uses an
> identical copy of the same function introduced by 8c9c051b (setup.c:
> introduce `die_upon_dubious_ownership()`, 2024-04-15), and reverting
> f4aa8c8b mechanically out of the merged result in v2.45.1 would
> likely to remove the function that is still in use, which would need
> to be retained.

Well the result can be seen at

    https://lore.kernel.org/git/20240521195659.870714-1-gitster@xxxxxxxxx/

but I am inclined to say that its [12/12] (partial reversion of
f4aa8c8b) is highly questionable, after thinking about it a bit
more.  It is true that you can run git-daemon as 'nobody', let it
peek into repositories owned by real users, feeling safe that
'nobody' would not be able to harm these repositories at all.  

But unless this is a tightly controlled hosting environment where no
repository owned by "real users" have malicious hooks and config
files, a "real user" could attack "nobody", and the safe.directory
mechanism that is over-agressive in denying things may alleviate the
problem.  At places like k.org where the repository data including
its hooks and configuration files are trusted, setting up the
configuration safe.directory in the ~nobody/.gitconfig to cover the
real user repositories would probably be a simple enough workaround.






[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux