On 11/06/2012 01:45 PM, Simo Sorce wrote: > 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. Following the first bullet in man page "if all lists are empty the access is granted". It works as advertised right? So I do not see why anything needs to be changed then.
> > 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. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
