Proposition for new remctl ACL scheme / group support

[Rémi Ferrand]

On 03/07/2014 06:20, Russ Allbery wrote:
> Thank you very much for this work!
>
> I have now finally merged it and pushed out a new release, as you probably
> just saw.  Unfortunately, we use Gerrit internally in a way that doesn't
> work well with merges, so the line of development doesn't look like a
> merge of your branch in Github.  (There are ways to fix this, but they
> were all too complex than I had time for.)  But your patches, rebased, are
> in there, along with some subsequent refactoring.
Perfect, this will be a major improvement for us at CC-IN2P3, thank you 
for this release !

>
> I haven't had a chance to take a look at the PTS ACL code yet,
> unfortunately.  I have a few other things queued up to look at before I'll
> get a chance to poke at it.
Since my last e-mail to this list, I didn't very much time to work on 
this ACL scheme, but I'm still waiting for any kind of comments as 
dealing with AFS libraries could be tricky.


This morning, I was looking at your remctl TODO-List 
(http://www.eyrie.org/~eagle/software/remctl/todo.html) and I'm quite 
excited about what I've seen !

Two particular items retain my attention:

* REMCTL-7: Support LDAP-based ACLs in addition to file system ACLs. 
Probably need to support both entitlement and group-based ACLs.

Before starting to write the "getgrnam*" code, I was originally decided 
to write some OpenLDAP code/binding (as discussed with K. Dreyer at the 
Kerberos conference at CERN) but then I changed my mind.
Do you already have a proof of concept of this functionnality ? I'll be 
glad to help on this.
The main issue I see here is: "how to specify the ACL".
Some ideas I had in my mind were:
  - Maybe something like "ldapgroup:THEGROUP:ldaps://host:port/...etc... 
(I choosed to put the LDAP connection string after the group name, this 
could make it easier to parse). This solution is quite hugly (IMHO) but 
allows one to use one LDAP connection string specific to one ACL. I 
don't really like this solution anyway.

  - Maybe something like "ldapgroup:THEGROUP", then the connection 
credentials to the LDAP server should be specified somewhere else. For 
instance something like "ldapconnection_string 
ldaps://host:port/...etc..." in the global remctld.conf.
I like this "plugin configuration/initialization approach" but I think 
that it could require some modifications in the "configuration file" 
parsing code, isnt' it ?

- Maybe the best solution for the final user could be to create a 
dedicated "option", something like:
 >> command   subcommand   executable 
ldap_connection_string=ldaps://host:port/...etc...    acl1 
ldapgroup:THEGROUP      ... aclN
If I'm right, the easiest way to do so would be to pass the whold 
"struct rule" to functions "acl_check_XXX".


* REMCTL-8: Add support for external ACL checking programs. If the 
program exits with a zero status, access is granted. If it exits 1, 
access is not granted but checking continues. If it exits with any other 
exit status, access is not granted and checking aborts. Ideally, for 
writing generic ACL checking programs, the program should get the type 
and service of the remctl command as well as any arguments. However, it 
would also be good to support passing other arguments into the program 
as specified in the ACL file.

I'll also be glad to help.
My question is quite the same as for the LDAP scheme configuration: how 
would you like the final user to pass arguments to the external checking 
program ?
Can you also clarify the "for writing generic ACL checking programs, the 
program should get the type and service of the remctl command as well as 
any arguments" for me please ? For instance, with a remctl command such 
as "command subcommand executable", what's the "type" and what's the 
"service" ?


Cheers

Rémi