[36280] in Kerberos
Re: Proposition for new remctl ACL scheme / group support
daemon@ATHENA.MIT.EDU (=?ISO-8859-1?Q?R=E9mi_Ferrand?=)
Thu Jul 17 08:25:33 2014
Message-ID: <53C7C022.3050508@cc.in2p3.fr>
Date: Thu, 17 Jul 2014 14:22:58 +0200
From: =?ISO-8859-1?Q?R=E9mi_Ferrand?= <remi.ferrand@cc.in2p3.fr>
MIME-Version: 1.0
To: Russ Allbery <eagle@eyrie.org>
In-Reply-To: <8761jff4z9.fsf@windlord.stanford.edu>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: multipart/mixed; boundary="===============1416466500=="
Errors-To: kerberos-bounces@mit.edu
This is a cryptographically signed message in MIME format.
--===============1416466500==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary="------------ms000408040001050908000401"
This is a cryptographically signed message in MIME format.
--------------ms000408040001050908000401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
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 proba=
bly
> 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=20
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=20
this ACL scheme, but I'm still waiting for any kind of comments as=20
dealing with AFS libraries could be tricky.
This morning, I was looking at your remctl TODO-List=20
(http://www.eyrie.org/~eagle/software/remctl/todo.html) and I'm quite=20
excited about what I've seen !
Two particular items retain my attention:
* REMCTL-7: Support LDAP-based ACLs in addition to file system ACLs.=20
Probably need to support both entitlement and group-based ACLs.
Before starting to write the "getgrnam*" code, I was originally decided=20
to write some OpenLDAP code/binding (as discussed with K. Dreyer at the=20
Kerberos conference at CERN) but then I changed my mind.
Do you already have a proof of concept of this functionnality ? I'll be=20
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=20
could make it easier to parse). This solution is quite hugly (IMHO) but=20
allows one to use one LDAP connection string specific to one ACL. I=20
don't really like this solution anyway.
- Maybe something like "ldapgroup:THEGROUP", then the connection=20
credentials to the LDAP server should be specified somewhere else. For=20
instance something like "ldapconnection_string=20
ldaps://host:port/...etc..." in the global remctld.conf.
I like this "plugin configuration/initialization approach" but I think=20
that it could require some modifications in the "configuration file"=20
parsing code, isnt' it ?
- Maybe the best solution for the final user could be to create a=20
dedicated "option", something like:
>> command subcommand executable=20
ldap_connection_string=3Dldaps://host:port/...etc... acl1=20
ldapgroup:THEGROUP ... aclN
If I'm right, the easiest way to do so would be to pass the whold=20
"struct rule" to functions "acl_check_XXX".
* REMCTL-8: Add support for external ACL checking programs. If the=20
program exits with a zero status, access is granted. If it exits 1,=20
access is not granted but checking continues. If it exits with any other =
exit status, access is not granted and checking aborts. Ideally, for=20
writing generic ACL checking programs, the program should get the type=20
and service of the remctl command as well as any arguments. However, it=20
would also be good to support passing other arguments into the program=20
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=20
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=20
as "command subcommand executable", what's the "type" and what's the=20
"service" ?
Cheers
R=E9mi
--------------ms000408040001050908000401--
--===============1416466500==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1416466500==--
