Discussion:
Bug#934052: base-passwd: new static group for hamradio packet
(too old to reply)
Iain R. Learmonth
2019-08-06 13:20:01 UTC
Permalink
Package: base-passwd
Version: 3.5.46
Severity: normal

Control: affects -1 + xastir ax25-apps ax25-tools axmail uronode aprsdigi ax25-xtools fbb
Control: block 933810 by -1

Hi,

There are many applications that would like to use AX.25 sockets. Often
these applications require the CAP_NET_RAW and/or CAP_NET_ADMIN
filesystem permissions in order to function (or they are setuid/run as
root).

In #185915 I added a new dynamic group for Xastir (xastir-ax25) to
enable the use of Xastir with AX.25 sockets for non-root users.

In #933810 we are facing the same problem, and while we could create
another dynamic group it is probably better to standardise on one static
group created for this purpose.

I have listed other packages that would benefit from this change in the
affects list, as these are currently requiring the application be run as
root. Once the new group is created we will consider those applications
that can use filesystem capabilities instead of running as root to be
buggy if they require root.

Please let me know if more information is required.

Thanks,
Iain.
Colin Watson
2019-08-11 18:20:01 UTC
Permalink
Post by Iain R. Learmonth
There are many applications that would like to use AX.25 sockets. Often
these applications require the CAP_NET_RAW and/or CAP_NET_ADMIN
filesystem permissions in order to function (or they are setuid/run as
root).
In #185915 I added a new dynamic group for Xastir (xastir-ax25) to
enable the use of Xastir with AX.25 sockets for non-root users.
In #933810 we are facing the same problem, and while we could create
another dynamic group it is probably better to standardise on one static
group created for this purpose.
I have listed other packages that would benefit from this change in the
affects list, as these are currently requiring the application be run as
root. Once the new group is created we will consider those applications
that can use filesystem capabilities instead of running as root to be
buggy if they require root.
Hi,

It's normally OK to share a dynamic group between several cooperating
packages for this sort of thing; there's no intrinsic reason why just
being used by several different packages requires a static group. Where
possible we do prefer the use of dynamic groups, and from what you've
said so far I'm not yet quite clear why a shared dynamic group wouldn't
be possible. (Note that allocations in the 0-99 range that are
pre-created on every system are vanishingly rare; static allocations are
almost always in the 60000-64999 range, and for those you still need to
use adduser to create the actual accounts on users' systems on demand,
so a static allocation doesn't save you from needing some cooperation
between packages here.)

The only reasons to require statically-allocated IDs are normally:

* if it's necessary for some reason to encode the ID in a binary, and
it can't straightforwardly be changed to look up the ID at run-time
instead using getpwnam/getgrnam or similar

* if the ID has to be consistent across different machines due to
things like network file systems

Can you review your request in light of the above? It may be that I'd
be happy to allocate a static ID given more information on why it's
required, but perhaps this is just a misunderstanding and a dynamic ID
would be fine.

Thanks,
--
Colin Watson [***@debian.org]
Loading...