Proposition for new remctl ACL scheme / group support

[Russ Allbery]

This is pretty much where people talk about remctl.  I can create a new
mailing list if the traffic gets too annoying for other Kerberos folks,
but I kind of like having a broader audience as long as others don't mind.

Remi FERRAND <remi.ferrand at cc.in2p3.fr> writes:

> We were unable to find a simple way to do this with the current remctl
> ACL methods, that's why we've submited a first patch
> (https://github.com/rra/remctl/pull/1).  This patch introduces a new ACL
> method named "unxgrp" and is still not merged in master.  It was an easy
> (and fast to write) answer to our problematic.

Oh, I forgot to comment on one thing: would it cause you a bunch of
problems if I renamed that ACL to "localgroup"?  I try to avoid cryptic
abbreviations if possible, and I think it's worth emphasizing that this is
a group based on the local version of the principal.  (Although I could
probably be talked into "unixgroup".)

Other than that, I'm hoping to merge that soon.  Thank you for your work!

> we could be able to use the following ACL in remctl configuration file:

>>>> pts_group:remctl:testgrp

> to allow user1 and user2 to execute a command.

> Before any further development, we'd like to know if someone could be
> interested in that feature ?  Does someone think that we absolutely
> shouldn't do that ?  If so we'll talk later of the implementation.

> More important for us, we'd like to know what Russ Allbery thinks about
> that as he is the main developper of remctl.

Sure, that would be fine.  It would need to be built optionally based on
whether the AFS libraries are available, of course.  I'd advocate for just
calling it "pts".

The only other thing that I'm not sure about is how annoying it is to set
up and tear down the libraries that let you do PTS queries.  I'm pretty
aggressive about making sure that the remctl server is entirely clean
about memory allocation and free and not leaking file descriptors to child
processes, and the OpenAFS libraries often have some difficulties there.

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>