New remctl ACL scheme and execution of external ACL checking program

Rémi Ferrand remi.ferrand at cc.in2p3.fr
Tue Aug 5 11:55:39 EDT 2014


Sorry for the spam, afterwards I realized that this was more appropriate 
to open a new thread for this very subject.

Regards

Rémi


On 17/07/2014 14:22, Rémi Ferrand wrote:
>
> * 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've started to think about this feature and I think that this could be 
a great enhancement to be able to access to requested command, 
subcommand and args in the "acl_check_" functions (I guess that by "type 
and service of the remctl command as well as any arguments" you meant 
"command, subcommand and args", didn't you ?)


I've created https://github.com/rra/remctl/pull/2 as a proposal but this 
could be a little "naïve" since it was very straightforward.
This should be more considered as a "discussion starter" about how to 
grant access to command, subcommand and args to "acl_check_" functions.


Talking about the support for external ACL checking programs,
for now my idea is to have a configuration line like:


testcmd ALL /usr/bin/myprogram.pl exec_extra_arg="--arg1 --arg2 
--arg-with-value='foo'" exec:/path/to/acl_checking_command.pl


with the new "exec" (or something like this) ACL scheme that would 
execute the external program "/path/to/acl_checking_command.pl" and 
check for its return code to allow/deny access or continue ACL processing.


My idea was that the program "/path/to/acl_checking_command.pl" would 
always receive those arguments:

--user="remote user authenticated throw gssapi"
--command="requested command"
--subcommand="requested subcommand" (if subcommand is not NULL)

(people that, in the future, would write external validation scripts 
MUST support those options)


and if option "exec_extra_arg" is used in configurationn file, then 
those extra arguments should be appended to previous mandatory ones, 
which could lead to the final execution of


/path/to/acl_checking_command.pl \
    --user="the_user" \
    --command="the_command" \
    --subcommand="subcommand_if_any" \
    --arg1 \
    --arg2 \
    --arg-with-value='foo'


Everything above is just a proposal and opened to discussion, actually 
I'll be glad to have other ideas / opinions.

Cheers

Rémi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2940 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20140805/8130b17c/attachment-0001.bin


More information about the Kerberos mailing list