guix-patches
[Top][All Lists]
Advanced

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

[bug#49814] [PATCH] accounts: Add <group-membership>.


From: Ludovic Courtès
Subject: [bug#49814] [PATCH] accounts: Add <group-membership>.
Date: Tue, 10 Aug 2021 15:06:13 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

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 via email to

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