[Engine-devel] Local Authentication Feature

Juan Hernandez jhernand at redhat.com
Mon Feb 11 09:17:01 UTC 2013


On 02/11/2013 09:18 AM, Oved Ourfalli wrote:
>
>
> ----- Original Message -----
>> From: "Doron Fediuck" <dfediuck at redhat.com>
>> To: "Andrew Cathrow" <acathrow at redhat.com>
>> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
>> Sent: Monday, February 11, 2013 9:27:32 AM
>> Subject: Re: [Engine-devel] Local Authentication Feature
>>
>>
>>
>> ----- Original Message -----
>>> From: "Andrew Cathrow" <acathrow at redhat.com>
>>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
>>> Sent: Sunday, February 10, 2013 7:21:32 PM
>>> Subject: Re: [Engine-devel] Local Authentication Feature
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>>> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>,
>>>> engine-devel at ovirt.org
>>>> Sent: Sunday, February 10, 2013 11:02:39 AM
>>>> Subject: Re: [Engine-devel] Local Authentication Feature
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>,
>>>>> engine-devel at ovirt.org
>>>>> Sent: Sunday, February 10, 2013 5:37:10 PM
>>>>> Subject: Re: [Engine-devel] Local Authentication Feature
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>>>>> To: "Juan Hernandez" <jhernand at redhat.com>
>>>>>> Cc: engine-devel at ovirt.org
>>>>>> Sent: Sunday, February 10, 2013 5:26:52 PM
>>>>>> Subject: Re: [Engine-devel] Local Authentication Feature
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>>>> To: engine-devel at ovirt.org
>>>>>>> Sent: Friday, February 8, 2013 7:50:36 PM
>>>>>>> Subject: [Engine-devel] Local Authentication Feature
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I would like to propose a new feature that allows
>>>>>>> authentication
>>>>>>> using
>>>>>>> the local user database. The details are here:
>>>>>>>
>>>>>>> http://www.ovirt.org/Features/Local_Authentication
>>>>>>>
>>>>>>> And the proposed change is available for review here:
>>>>>>>
>>>>>>> http://gerrit.ovirt.org/11863
>>>>>>>
>>>>>>> I appreciate feedback.
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>> Juan Hernandez
>>>>>>
>>>>>> Hi Juan,
>>>>>> Very happy to see this one which actually closes an annoying
>>>>>> gap!
>>>>>> One thing which is missing is user management-
>>>>>> add/remove/change
>>>>>> users and groups. If we do not plan to handle it within
>>>>>> ovirt,
>>>>>> the
>>>>>> design should state it and explain how user management should
>>>>>> work.

User management is not included in the feature, like it isn't currently 
with LDAP. The administrator has to use external tools to manage that 
database, then use the GUI to add the users and give them permissions. I 
updated the description accordingly.

>>>>>
>>>>> Shouldn't this be the same as in case of external directory
>>>>> service?
>>>>> i.e - you manage user/group at the directory service, and then
>>>>> you
>>>>> "populate" engine with it (by adding permissions to
>>>>> users/groups
>>>>> or
>>>>> adding explicitly new users/groups to engine?)
>>>>>
>>>>>> Also, what happens when a user is removed from the local DB-
>>>>>> will
>>>>>> all references to him be removed? Groups?
>>>>>
>>>>> IMHO the behavior in this case should be as in case of current
>>>>> LdapBroker.

Yes, the behavior is the same, the engine refreshes its database from 
the external system (I need to test this).

>>>>>
>>>>
>>>> This could be a decision but it's missing from the design.
>>>> The diff I see from current supported directory servers are that
>>>> they actually have their own management tools, which is not the
>>>> case for local DB. Again, you may state that the various userXXX
>>>> and groupXXX commandline utilities are the way to manage it, but
>>>> this is lacking from the design.
>>>
>>> Local user support is a feature we certainly need, but somehow
>>> ssh'ing into the node feels wrong.
>>> A local db is better than the (creative) ssh hack.
>>>

An additional database is better in some scenarios (probably in most 
scenarios) but there are scenarios where using the local database is 
still better. For example if already using NIS or if you just need a few 
users that are already users (or will be) of the system where you are 
installing the engine.

>>>
>> IIUC it's an internal SSH just for the authentication part.
>> If it succeeds the user is authenticated. Otherwise the user
>> will fail to login. That's the only use of the ssh. everything
>> else should work as it used to so far.
>>

SSH is used only for authentication. Users don't need a home directory 
or permission to use a shell. A typical user would be added like this:

useradd -M -s /sbin/nologin -c 'Whatever' whatever

In addition the SSH used for authentication is completely local, so 
external SSH access could be blocked by the firewall and authentication 
will still work.

>
> I also wouldn't say it is a hack, but on the other hand requiring it for such a feature feels wrong to me as well.
> Some sysadmins also choose to disable SSH for security reasons, so it won't work for them.
> Isn't there an option to use PAM instead? Something similar?
>

This feature doesn't use PAM at all, it only uses NSS. Using PAM for 
authentication requires a component with root permissions (be it the 
program itself or an external binary with SUID permissions). We don't 
have such thing. You can think of the SSH server as that external binary.

> As for using local DB, I think it is a different feature than this one, so they can both co-exist.
>
> Oved

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.



More information about the Engine-devel mailing list