> >> >> I think that an explicit allow list is usually way better because with >> deny rules it's easy to fail to enumerate all entities that should be >> denied, resulting in allowing access we didn't want to. >> >> However, does anyone still remember why we opted for deny rules during >> design phase in the first place? > > IMO it was convenience. > >> Was it a compatibility with some existing system (that our users might >> be migrating from) or just to provide a convenient construct to our >> users? > > No other system we know of does this. > >> >> By removing the deny rules, do we break compatibility with anything >> else than the IPA tech preview in RHEL and upstream FreeIPA 2.0? > > > Not that we know of. We break Fedora compatibility but we can handle it > with the smart upgrade script that detects the presence of the deny > rules and bails out before updating the system asking user to fix deny > rules manually before updating. >>
The Sudo implementation for FreeIPA has looked to HBAC for direction and similarity in a lot of ways. I would ask if we are going to remove 'deny' that we leave those pieces in reach for reference in future use when Sudo will need to try to integrate, as Sudo want to have both permit and deny rules. _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
