Hi Colin, Thanks for the speedy reply!
On Wed, Apr 01, 2015 at 11:20:43PM +0100, Colin Watson wrote:
> 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.
Awesome! Yep, dynamically-allocated group is the plan.
> 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")?
That seems a sane change to me. If there were going to be updates to the
policy, I would also like to see mention of capabilities and that they
should be preferred over setuid (although falling back is allowed on systems
where capabilities do not work). I may take a look at drafting some changes
regarding that once I've finished my current queue.
Thanks,
Iain.
--
e: i...@fsfe.org w: iain.learmonth.me
x: i...@jabber.fsfe.org t: EPVPN 2105
c: 2M0STB g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49
pgp9NZW53O8H4.pgp
Description: PGP signature
