Subject: bug#56444: [EXT] Re: [EXT] Re: bug#56444: Patch to fix Gitolite home directory permissions

From: "Thompson, David" <[email-masked]>
Date: Mon, 29 Aug 2022 09:30:58 -0400

On Mon, Aug 29, 2022 at 9:19 AM Maxime Devos <[email-masked]> wrote:

> On 29-08-2022 14:57, Thompson, David wrote:
>
> > I disagree.  I believe we shouldn't let perfect be the enemy of the good.
>
> I don't think your patch counts as "good" here -- while fixing the bug
> counts as "good", you are at the same time introducing a new bug (the
> non-atomicity), which is bad.  You would have to weigh the goodness and
> the badness to end up with an overall "good" (or maybe "bad", depending
> on the conclusion), but I'd think that the time required to do such a
> weighing is better spent by doing a tiny bit of extra effort to
> implement the new field (it should be very low effort, see other response).
>

My patch has a very limited scope of only changing the gitolite service.
Your proposal has a much greater scope of modifying a core structure used
for system configuration.  The new bug you mention is only bad in a
theoretical sense.  In practice, the permission bits are misconfigured for
a blip of time during system reconfiguration, which is a lot better than
being misconfigured all the time which is the status quo.  It's the
difference between a gitolite that works nicely with cgit/gitweb and one
that doesn't. I agree that it's a good goal to improve atomicity and I
think making <user-account> more general to allow for different permission
bits on the home directory is a good idea, but I see it as one step removed
from fixing this particular bug.  My patch follows the recommended approach
outlined in a comment in (gnu build activation) written by Ludovic in 2019:

      ;; Always set ownership and permissions for home directories of system
      ;; accounts.  If a service needs looser permissions on its home
      ;; directories, it can always chmod it in an activation snippet.

- Dave