From: Joachim Wiberg <troglobit@gmail.com>
To: Vincent Jardin <vjardin@free.fr>
Cc: buildroot@buildroot.org, Vadim Kochan <vadim4j@gmail.com>,
thomas.petazzoni@bootlin.com
Subject: Re: [Buildroot] [PATCH 1/1] package/frr: make vtysh group configurable
Date: Wed, 05 Feb 2025 05:14:08 +0100 [thread overview]
Message-ID: <f07db2bf9668c00e911ffbc161551d875ffdb96f.camel@gmail.com> (raw)
In-Reply-To: <dq3i7hbdwatnngs4zix4pe3bwnv64fjca4i3krbjr3yccy3b4v@wjik7jr5er7z>
[-- Attachment #1.1: Type: text/plain, Size: 1901 bytes --]
Hi Vincent!
On Wed, 2025-02-05 at 02:28 +0100, Vincent Jardin wrote:
> Why would you enforce a frrvty user to any other value ? Can you
> explain the rational of not using the Buildroot's default value ?
Currently, non-root users of a Buildroot system, that you want to give
administrator privileges to manage the system, i.e., edit system files
and configure Frr daemons using vtysh, need to be member of two groups:
wheel and frrvty.
I propose opening up that so it is up to the Buildroot user (developer)
how they model their end system.
> Even if FRR has such capability, it does not mean we should expose it.
This Frr build-time setting controls the group which an administrator
user in a system must be member of to be able to access vtysh over its
UNIX socket, it cannot be set set or changed in another way after build.
A variant of the same patch that would work for my own use-case, and in
some way align with Buildroot defaults, would be to change what we hard-
code it to:
--enable-vty-group=wheel
I did not think such a patch would fly at all, in particular since it is
not backwards compatible. Which is why I went with this approach where
the developer can at least decide the group of users should be able to
manage Frr now that it has shifted to everything-via-vtysh from per-
daemon .conf files as their default.
> Your suggestion starts adding some complexities. Based on the same
> model, if we
> follow it, we should do the same for:
> --enable-user=frr
> --enable-group=frr
> too. That's why I would be strongly interested in reading your
> rationals for such capability.
I see, well that was not my intention at all to imply. The latter is
for privilege separation of the daemons themselves, I don't see any
value to a user of Buildroot to be able to change that for any package.
All the best
/Joachim
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 150 bytes --]
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2025-02-05 4:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-06 20:34 [Buildroot] [PATCH 1/1] package/frr: make vtysh group configurable Joachim Wiberg
2025-01-06 21:11 ` Thomas Petazzoni via buildroot
2025-01-06 21:27 ` Joachim Wiberg
2025-02-05 1:28 ` Vincent Jardin
2025-02-05 4:14 ` Joachim Wiberg [this message]
2025-02-05 8:48 ` Arnout Vandecappelle via buildroot
2025-02-05 8:51 ` Arnout Vandecappelle via buildroot
2025-02-05 9:00 ` Joachim Wiberg
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=f07db2bf9668c00e911ffbc161551d875ffdb96f.camel@gmail.com \
--to=troglobit@gmail.com \
--cc=buildroot@buildroot.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=vadim4j@gmail.com \
--cc=vjardin@free.fr \
/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.
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.