[Freeipa-devel] Data source-agnostic parameters

[Jan Cholasta]

Dne 6.8.2012 16:27, John Dennis napsal(a):
> 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
>

Not necesarrily, RFC 3986 allows the former format (but AFAIK there is 
no RFC which allows relative file names in the URIs).

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

Sure, these are just ideas, not something absolutely necessary.

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

Both "default" and "ask" are scheme names in my proposal (the URIs using 
these schemes don't have anything after the colon, but the colon must be 
present).

The only use of "default:" is when a parameter has a default value and 
the always_ask flag set, but you don't actually want the CLI to prompt 
for it.

Honza

-- 
Jan Cholasta