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

Re: New system group for Xastir AX.25 users



On Wed, Apr 01, 2015 at 10:47:18PM +0100, Iain R. Learmonth wrote:
> I am working on the xastir package [1] which is maintained by the Debian
> Hamradio Maintainers team. A wishlist bug has been filed on this package
> (#185915 [2]) requesting the addition of a debconf option to have the binary
> installed setuid to allow for access to the native AX.25 available in Linux.
> 
> According to Debian policy §10.9, the preferred method of doing this is
> through the creation of a group, and users that are allowed to run the
> binary setuid are a member of this group. I also intend to attempt to set
> capabilities first, falling back to setuid if that option is not available.
> 
> The "capabilities first, fall back to setuid" approach is also used by the
> wireshark and iputils packages.
> 
> The same policy section states that the new group name should be discussed
> on debian-devel and with the base-passwd maintainer, and so this email
> serves to start that discussion.
> 
> I propose the group name "xastir-ax25" for this purpose. This uses only
> allowable characters and is 11 characters long (the maximum being 16), and
> so is a valid group name. Are there any objections to this name being used?

I have no objections to the group handling here.  It sounds as though
you can and therefore should use a dynamically-allocated group, in which
case there's no need for any action from me as base-passwd maintainer.

In fact, I had not realised that policy says that developers should
contact the base-passwd maintainer in the common case of creating
dynamically-allocated users or groups.  This doesn't scale terribly
well, and most developers do not in practice do this, for which I am
grateful!  Discussion on debian-devel seems reasonable enough as
technical review, but I can't really imagine the situation where I would
steer people in the direction of static allocation when it can feasibly
be avoided.  Would anyone object to me seeking to remove that clause
from policy ("and checking with the base-passwd maintainer that it is
unique and that they do not wish you to use a statically allocated id
instead")?

-- 
Colin Watson                                       [cjwatson@debian.org]


Reply to: