[Freeipa-devel] Data source-agnostic parameters

[John Dennis]

On 08/06/2012 10:10 AM, Alexander Bokovoy wrote:
> On Mon, 06 Aug 2012, Jan Cholasta wrote:
>> Dne 6.8.2012 15:20, Simo Sorce napsal(a):
>>> On Mon, 2012-08-06 at 10:55 +0200, Jan Cholasta wrote:
>>>> Hi,
>>>>
>>>> while thinking about <https://fedorahosted.org/freeipa/ticket/2933>, I
>>>> had an idea how to make loading data from files available for all
>>>> parameters:
>>>>
>>>> I think we can use URI-like strings in parameter values that the CLI
>>>> would interpret and extract the wanted information from them (similar to
>>>> what openssl does in the -pass command line option, see PASS PHRASE
>>>> ARGUMENTS in openssl(1)).
>>>>
>>>> So, instead of adding a new parameter as a file-accepting alternative to
>>>> any existing parameter (i.e. what is suggested in the ticket), the user
>>>> would be able to specify the file in a URI-like string:
>>>>
>>>> (use new parameter --sshpubkeyfile)
>>>> $ ipa user-mod --sshpubkey="ssh-rsa AAAA ..."
>>>> $ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub
>>>>
>>>> vs.
>>>>
>>>> (use file URI-like string)
>>>> $ ipa user-mod --sshpubkey="ssh-rsa AAAA ..."
>>>> $ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub
>>>>
>>>> and the CLI would take care of reading the file and using its contents
>>>> as the parameter value.
>>>>
>>>> This could be extended with additional URI(-like) schemes:
>>>>
>>>>     - data:<data> - use <data> as the value (useful for escaping values
>>>> that look like URIs, but you don't want them to be treated as such)
>>>>     - base64:<data> - use the value of base64 decoded <data> (useful for
>>>> --delattr on ugly raw binary values)
>>>>     - fd:<num> - read value from file descriptor <num>
>>>>     - env:<var> - read value from environment variable <var>
>>>>     - ask: - always prompt interactively for the value
>>>>     - default: - use default value, never prompt interactively
>>>>
>>>> Thoughts?
>>>
>>> How do you handle values that are actually URI strings, how do you tell
>>> the command to not interpret them ?
>>>
>>> Simo.
>>>
>>
>> You can escape them like this: --someparam data:actual://uri/string
>>
>> As for backward compatibility, this change has the potential to break
>> things (user scripts which use the CLI, etc.), but AFAIK there is no
>> parameter in IPA which expects URI string values specifically, so the
>> impact would be miminal IMHO.
>
> I don't think you need to invent anything here. RFC2397 is available for
> long time and provides already effective way to represent any data in
> URI.
>
> http://tools.ietf.org/html/rfc2397

I think it would be much better to follow RFC's including the one 
Alexander cited above.

Rather than

$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub

shouldn't it be:

$ ipa user-mod --sshpubkey=file:///.ssh/id_rsa.pub


I'm not sure we need or want to pass file descriptors and I wonder about 
the security implications of reading from environment variables. So I'm 
not sure about supporting the fd and env input.

I don't think we need 'default' either, if the parameter does not begin 
with URI syntax then it's processes just as before.

I can see a value in 'ask', but I'd rather see this expressed as a URI 
scheme.

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/