9:39 a.m.
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)