guix-patches
[Top][All Lists]
Advanced

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

[bug#72398] [PATCH v2] services: Add readymedia-service-type.


From: Bruno Victal
Subject: [bug#72398] [PATCH v2] services: Add readymedia-service-type.
Date: Fri, 23 Aug 2024 16:25:18 +0100
User-agent: Mozilla Thunderbird

Hi Arun,

On 2024-08-23 00:28, Arun Isaac wrote:
> 
>>>> +(define %readymedia-user-account "readymedia")
>>>> +(define %readymedia-user-group "readymedia")
>>>
>>> I think it would be better to expose this in the
>>> readymedia-configuration record-type and have it be oriented around
>>> user-account and user-group record-types, i.e.
>>
>> Fixed, although I'm not sure I'm 100% on board with this.
>>
>> I'm not completely sure but I have the feeling that a configurable
>> ReadyMedia user might theoretically weaken the POLA, e.g. if the user
>> chose their own user for this service.
>>
>> Following up on a related conversation we started on IRC, I suppose we
>> should either go all in with flexibility (i.e. allow the user to switch
>> off the least-authority-wrapper and set the service user) or adopt a
>> slightly more rigid approach (mandated POLA and fixed user).
>>
>> I think I might have a slight preference for the latter, prioritising
>> compartmentalisation over flexibility - but I'm keen to know what you,
>> Arun, and all other Guixers may think about this.
> 
> I am with Fabio on this. Many (almost all, maybe?) services use a fixed
> user account that cannot be configured. And, that's ok.

Without delving into the quantifying, there's at least a few of them
that offer this feature. (in my experience, I've had to rely on this for a
few services already so it's not merely a theoretical concern)

Should you ever need to "tweak" a fixed user-account service
you're going to end up with something like [1] (beginning from line 21,
rationale given at line 39). Not exactly desirable and although the
example above pertains to nginx + cgit if I'm not mistaken, a similar
situation arises in the following (fictional) setup:

/media/NFS/my-media/…             (owner: foo, group: bigmedia, #o750)
/media/jumbodisk/my-media/…       (owner: bar, group: bigmedia, #o750)
/media/something-else/library/…   (owner: baz, group: bigmedia, #o750)

and wholesame chown'ing them to "readymedia" wouldn't make sense/be
a good idea (say, each of the directories is under control by a
downloader/synchronizing daemon with it's own user-account).

> I don't think we should make the least authority wrapper optional
> either. Making it optional would be too much complexity for little
> benefit. (…)

I don't think so, it amounts to:
• a boolean field named least-authority-wrapped? in the configuration 
record-type
• an if statement, e.g. (if least-authority-wrapped? (least-authority-wrapper 
…) readymedia)

As for the reason of this, consider a setup where the media directories
contain symlinks to directories outside of it. It can be infeasible to
duplicate the files or "just move them then", in those cases an escape
hatch makes sense to be. It's not as secure as the least-authority wrapped
 one but that's a compromise opted in by the user.

> (…) The goal of Guix services isn't to provide total
> configurability, but rather to be slightly opinionated so as to nudge
> users in the right direction.

I'm not against this idea, just pointing out that it's overly rigid right
now and that users with a non "uniform" setup will simply resort to
harder to understand manipulations like [1] or wholesale duplicate
gnu/services/upnp.scm and tweak it themselves.

Let me know if there's anything I missed,


[1]: 
<https://git.dthompson.us/guix-config/tree/dthompson/machines/takemi.scm?id=b14a123560dbfc4b7b9ceedf12cc5730558e2418#n39>

-- 
Cheers,
Bruno.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]