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

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 3038 bytes --]


On 29-08-2022 15:30, Thompson, David wrote:
>
> On Mon, Aug 29, 2022 at 9:19 AM Maxime Devos <maximedevos@telenet.be> 
> 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.
It is a greater scope, but it's not really more effort.
> 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.

The time required to analyse it as "just theoretical" could have been 
spent doing the tiny bit of extra effort.

Theoretical bugs like these are especially nasty, if you encounter them 
there is often not a clue what the cause is unless you already know what 
to look for.

>   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.

I've refuted that recommendation (albeit without explicitly mentioning 
that paragraph), that paragraph is a bug, see my previous comments on 
non-atomicity. Please remove it in the v2 patch.

As there appears to be a lack of willingness to invest the tiniest bit 
of extra effort to implement a proper patch, and given the length of 
previous discussion, I think my time will be better spent continuing 
fixing things in Guix rather than any failing attempts at convincing 
you. As such, I'll stop responding until a v2 or questions on how to 
implement a v2, but that cannot be interpreted as me agreeing with you.

Greetings,
Maxime


[-- Attachment #1.1.1.2: Type: text/html, Size: 5064 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]