Re: 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:










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

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: (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:

Cheers

Rémi

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

smime.p7s
Description: S/MIME Cryptographic Signature

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos