From: Arun Isaac <arunisaac@systemreboot.net>
To: Bruno Victal <mirai@makinata.eu>, Fabio Natali <me@fabionatali.com>
Cc: 72398@debbugs.gnu.org
Subject: [bug#72398] [PATCH v2] services: Add readymedia-service-type.
Date: Wed, 28 Aug 2024 23:51:16 +0100 [thread overview]
Message-ID: <87h6b4ntwb.fsf@systemreboot.net> (raw)
In-Reply-To: <709c0681-3e94-48c4-ae57-f06327b7c6c8@makinata.eu>
Hi Bruno,
>> 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).
You're right about this problem. It's been discussed here as well:
https://issues.guix.gnu.org/67288 But, like I mention there, I am
worried that adding configurable user and group fields to every service
isn't very composable. Ideally, we'd want to have a separate
"add-user-to-group" service that can modify configured users to have
more groups. Such a solution may be more composable. WDYT?
>> 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.
Another solution could be to add a "mappings" field that specifies
additional directories to map into the container. I do this in some
services in
guix-forge. https://guix-forge.systemreboot.net/manual/dev/en/#item27237
It's probably not the most elegant solution, but it works without
completely disabling the container. Would this be acceptable to you?
Cheers, and happy hacking!
Arun
next prev parent reply other threads:[~2024-08-28 22:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-31 10:27 [bug#72398] [PATCH] services: Add readymedia-service-type Fabio Natali via Guix-patches via
2024-08-12 23:19 ` Arun Isaac
2024-08-19 0:27 ` Fabio Natali via Guix-patches via
2024-08-20 2:14 ` [bug#72398] [PATCH v2] " Bruno Victal
2024-08-22 10:13 ` Fabio Natali via Guix-patches via
2024-08-22 23:28 ` Arun Isaac
2024-08-23 11:04 ` [bug#72398] [PATCH v4] " Fabio Natali via Guix-patches via
2024-08-23 15:35 ` Bruno Victal
2024-08-26 10:11 ` [bug#72398] [PATCH v5] " Fabio Natali via Guix-patches via
2024-09-06 22:17 ` Ludovic Courtès
2024-09-08 20:04 ` [bug#72398] [PATCH v6] " Fabio Natali via Guix-patches via
2024-08-23 15:25 ` [bug#72398] [PATCH v2] " Bruno Victal
2024-08-28 22:51 ` Arun Isaac [this message]
2024-08-29 14:37 ` Fabio Natali via Guix-patches via
2024-08-22 23:22 ` Arun Isaac
2024-08-22 10:17 ` [bug#72398] [PATCH v3] " Fabio Natali via Guix-patches via
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6b4ntwb.fsf@systemreboot.net \
--to=arunisaac@systemreboot.net \
--cc=72398@debbugs.gnu.org \
--cc=me@fabionatali.com \
--cc=mirai@makinata.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).