On Mon, Aug 29, 2022 at 9:19 AM Maxime Devos <maximede...@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. 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
