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
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
