On Wed, 2014-06-04 at 16:11 +0200, Jakub Hrozek wrote:
> On Wed, Jun 04, 2014 at 09:58:20AM +0200, Sumit Bose wrote:
>> On Wed, Jun 04, 2014 at 08:42:21AM +0200, Jakub Hrozek wrote:
>>> On Tue, Jun 03, 2014 at 04:22:51PM -0400, Simo Sorce wrote:
>>>> On Tue, 2014-06-03 at 15:52 -0400, Stephen Gallagher wrote:
>>>>> On 06/03/2014 08:26 AM, Pavel Reichl wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I noticed that if using simple access provider and having
>>>>>> non-existing group or user in access/deny list then access will
be
>>>>>> denied and "su: System error" will be printed.
>>>>>>
>>>>>> I think it's OK to simply skip non-existing objects on
allow_list.
>>>>>>
>>>>>> I'm not so sure what to do in case of deny lists. Should we
also
>>>>>> just skip them or should we deny the user and print more
>>>>>> appropriate message ("su: Permission denied")?
>>>>>
>>>>> I agree that skipping (and logging) on allow lists is fine.
>>>>>
>>>>> For deny lists, it implies that either 1) the admin typoed the
>>>>> user/group name in the list or 2) that the user/group was removed
from
>>>>> LDAP.
>>>>>
>>>>> In the first case, we're potentially dealing with privilege
leakage
>>>>> (someone who shouldn't have access has it due to an admin
>>>>> misconfiguration). In the second case, this is perhaps just normal
>>>>> operating changes and shouldn't require client modification.
>>>>>
>>>>> As I type this, I become more certain that the correct approach here
>>>>> should be to log this with a better message (in both
>>>>> SSSDBG_CRIT_FAILURE and sss_log) and just proceed as if it didn't
exist.
>>>>>
>>>>> A better message would perhaps be:
>>>>> "The [user|group] %s does not exist. Possible typo in
>>>>> simple_[allow|deny]_[users|groups]"
>>>> The secure thing to do is to fail, because you do not know with
>>>> certainty who should be allowed.
>>> So if an admin typoes a group, noone can log in? That might effectivelly
>>> lock out legitimate access that would subsequently use sudo vi to fix the
>>> typo..
>> I think we can skip with a log message in the allow case because then
>> access is still only allowed if another entry matches.
>>
>> In the deny case I would prefer a reject as well. With this we would
>> make the allow list more comfortable to use and people might rethink
>> their deny list usage in environments where groups are often deleted or
>> renamed.
>>
>> bye,
>> Sumit
> OK, that sounds like a far compromise. I also hope noone would use the
> deny list then. Thanks!
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Hello,
new patches are attached.
1st patch:
I amended the debug messages as Stephen suggested.
Non-existing objects are ignored on allow lists, but imply access denied
on deny lists.
2nd patch:
amended mam page - documenting missing objects from deny lists.
3rd patch:
Minor optimization - don't continue matching username with names from
simple_allow_list after successful match.
I have rebased 1st and 3rd patch as there are users who might benefit
from the changes immediately.
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel