[SSSD] Unexpected behavior with 'simple_allow_users ='

Simo Sorce simo at redhat.com
Tue Nov 6 18:45:08 UTC 2012


On Tue, 2012-11-06 at 13:12 -0500, Dmitri Pal wrote:
> On 11/06/2012 10:50 AM, Simo Sorce wrote:

> > Just to be clear this is how I see it:
> >
> > config file  |   confdb     |   result
> > ----------------------------------------------------------
> > no attr      |   'ALL'      |  all user can access
> > empty attr   |    NULL      |  access is denied to all
> > user1, user2 | user1, user2 | only user1, user2 can access
> >
> >
> > Simo.
> >
> >
> 
> I am saying I do not like to hard code anything and rely on configdb
> contents at all.
> That changes semantics as in the past we did not rely on its contents.
> So I suggest to have two config values one is simple_allow_users and
> another simple_default_allow_rule (or similar, I am not married to name).
> The table is driven by the contents of the config file only (as it has
> been in the past with all other attributes):
> 
> simple_allow_users | simple_default_allow_rule | result
> --------------------------------------------------------
> user1, user2       |  ignored                  | user1, user2
> empty              |  ignored                  | access is denied to all
> no attr            |  no attr (default = ALL)  | all users can access
> no attr            |  "all"                    | all users can access
> no attr            |  "none"                   | access is denied to all  
> 
> Hope it makes sense now.

Yes, now I understand what you mean, but it is just too complex.
It is just not worth doing, it took me several minutes to understand the
table above, that tells me normal admins will just be confused and
writing documentation around how it works will be challenging, and we
call this 'simple' access method.

If this is the complexity we come to I think we should start
reconsidering the issue from scratch, so I went to the man page to see
what we say there:

        The simple access provider grants or denies access based on an
        access or deny list of user or group names. The following rules
        apply:
        
                • If all lists are empty, access is granted
                • If any list is provided, the order of evaluation is
                allow,deny. This means that any matching deny rule will
                supersede any matched allow rule.
                • If either or both "allow" lists are provided, all
                users are denied unless they appear in the list.
                • If only "deny" lists are provided, all users are
                granted access unless they appear in the list.


This tells me the expected behavior is that if all lists are empty the
access is granted (valid for the first 3 points).

For the latter point we just need to make sure that a value of 'ALL'
does not allow a user in if a deny list is provided.

So adding a default of 'ALL' to simple_allow_users (what I proposed) is
perfectly consistent with the current behavior (which is why i proposed
it).

The proposal is that if someone types: "simple_allow_users = " it means
that no users are in the list and access should simply be denied, this
currently does not work, access is still allowed.

We need to decide if we want to change this behavior or not.

If we want to change it then my proposal is sufficient, provided we
properly change the code, if not then let's do nothing.

I think adding another attribute is simply out of the picture, it makes
the whole scheme just way to complex just to handle an insignificant
corner case.

If that's the only viable agreement I propose we simply do nothing.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list