all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Brice Waegeneire <brice@waegenei.re>
Cc: 49814@debbugs.gnu.org
Subject: [bug#49814] [PATCH] accounts: Add <group-membership>.
Date: Tue, 10 Aug 2021 15:06:13 +0200	[thread overview]
Message-ID: <871r71sb3u.fsf@gnu.org> (raw)
In-Reply-To: <20210801212413.8906-1-brice@waegenei.re> (Brice Waegeneire's message of "Sun, 1 Aug 2021 23:24:13 +0200")

Hello,

Brice Waegeneire <brice@waegenei.re> skribis:

> As I was answerd on IRC, it's already possible to add groups to an already
> defined 'operating-system' by modifying it's 'user' field.  However this isn't
> that practical in my point of view.
>
> I would prefer to do such change from a service to be able to keep a potential
> new group and its members in proximity in the code.  For example when adding a
> sgid dumpcap binary to be used by the wireshark group members, it makes sense
> to keep the membership of that group close to the definition of the new group
> and its sgid binary:
>
> (simple-service 'wireshark-account account-service-type
>                 (list (user-group (name "wireshark") (system? #t))
>                       (additional-group-members "wireshark" %sysadmins)))
> (simple-service 'wireshark-dumpcap setuid-program-service-type
>                 (list (setuid-program
>                        (program (file-append wireshark "/bin/dumpcap"))
>                        (setuid? #f)
>                        (setgid? #t)
>                        (group "wireshark"))))

I understand the desire to keep these things close to one another, but I
must say I’m not convinced by this style.  I would do that along these
lines:

  (define (extend-account-membership group accounts)
    ;; Make ACCOUNTS members of GROUP.
    (map (lambda (account)
           (user-account
             (inherit account)
             (supplementary-groups
               (cons group (user-account-supplementary-groups account)))))
         accounts))

   (operating-system
     ;; …
     (users (extend-account-membership "wireshark" (list …))))

WDYT?

> This patch add a new <group-membership> record to be used as as some of the
> values for the 'account-service-type' which already support 3 other different
> types.

Any service could modify any other account using this, right?  There
might be cases where it’s nice to have such a sledgehammer, but it has
the downside that it makes it harder to reason about who does what in
the OS config—pretty much like NixOS modules can touch anything anywhere
in the config.

Thanks,
Ludo’.




      reply	other threads:[~2021-08-10 13:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-01 21:24 [bug#49814] [PATCH] accounts: Add <group-membership> Brice Waegeneire
2021-08-10 13:06 ` Ludovic Courtès [this message]

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871r71sb3u.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=49814@debbugs.gnu.org \
    --cc=brice@waegenei.re \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.