New remctl ACL scheme and execution of external ACL checking program

[Rémi Ferrand]

On 05/08/2014 17:55, Rémi Ferrand wrote:
> 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.
>
Using my previous patch I've created a "first version" of the external 
acl checking support here : 
https://github.com/ccin2p3/remctl/commit/fefb9f7820961bfef8f98dee8256bd4d86e19b47.
Same as my previous patch, this commit should be considered as a way to 
initiate a discussion about how this external ACL checking support 
should be implemented.

>
> 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)

This is not the way I finally choose:
* To propagate command, subcommand and user ... I've used environment as 
that's done in "server/process.c".
* Remote user supplied arguments are passed as arguments to the external 
ACL checking program.

For the special case where STDIN should be used with the *stdin* option, 
my idea was to supply STDIN to the external ACL checking program (as it 
would be done to the final program) ... this could allow very deep 
inspection about what is passed to the final program.

>
>
> 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
>
The main problem I have is about supplying extra arguments in the 
remctld configuration file ...
If I create a new option "exec_extra_arg", this will be a problem when 
there will be multiple ACL that uses "exec" in the same rule, as in:

testcmd ALL /usr/bin/myprogram.pl exec_extra_arg="--arg1 --arg2" 
exec:/path/to/acl_checking_command.pl 
exec:/path/to/other/acl_checking_command.pl

For now, I couldn't find a good way to specify those extra arguments, if 
anyone has an idea about it, just say it :-)


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/20140806/7f058aa1/attachment.bin