On Wed, Jun 28, 2017 at 03:29:02PM +0100, Howard Johnson wrote:
Cheers for the feedback.
On 2017-06-28 12:14, Alexander Bokovoy wrote:
We are going to introduce a special type of groups where membership reading would be limited to some conditions but this would not be relevant to HBAC, at least from my current understanding of the situation. This is to support organizational groups, not host-based access rights.
I guess at worst for this we might need a new set of role/privilege/permission that would allow viewing of all memberOf attributes.
On ti, 27 kesä 2017, Jakub Hrozek wrote:
There were requests to implement authentication over the D-bus interface in the past and we were quite reluctant to them, but IIRC that was because PAM handles prompting for the secrets, passing auth tokens and it's just well battle-tested.
Yeah, that absolutely makes sense.
But I don't see the same issues with an authorization call.
Excellent :)
I would prefer another interface than infopipe (authzpipe?), but in general, as long as the interface is restricted to authorization and not authentication, I don't see an inherent issue.
Would the authzpipe be another interface provided by sssd_ifp, or would you want another process (say, sssd_azp) to provide it?
I think reusing the same responder is OK, but I would prefer another interface. I don't know if we have any issues supporting multiple interfaces from the same process, but if we do, it's a bug and should be fixed.
I guess then if I were to start working up some patches, I wouldn't be wasting everyone's time? :)
Could you please write up a design page first?
Check e.g. https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html
The source can be found in our docs repo: https://pagure.io/SSSD/docs here: https://pagure.io/SSSD/docs/blob/master/f/design_pages/non_posix_support.rst (submitting a PR against the docs repo is enough)