[systemd-devel] pam_systemd.so indirectly calling pam_acct_mgmt

[Stephen Gallagher]

> On May 2, 2015, at 3:48 AM, Lennart Poettering <lennart at poettering.net> wrote:
> 
>> On Fri, 01.05.15 08:29, Stephen Gallagher (sgallagh at redhat.com) wrote:
>> 
>> Right, so based on this information, it seems to me that in SSSD we
>> need to be treating the 'systemd-user' PAM service the same way we do
>> the 'cron' service. The idea being that this is meant to handle
>> actions performed *as* a user but not *by* a user (for lack of a
>> better distinction).
>> 
>> In the terms of how Microsoft Active Directory would treat it (and
>> when we're using AD as the identity and authorization store), it
>> should be handled as the [Allow|Deny]BatchLogonRight permission which
>> is described by MS as:
>> 
>> "This security setting allows a user to be logged on by means of a
>> batch-queue facility.
>> 
>> For example, when a user submits a job by means of the task scheduler,
>> the task scheduler logs that user on as a batch user rather than as an
>> interactive user."
>> 
>> Does that seem to match everyone's expectation here?
> 
> Well, I guess for now. But note that eventually we hope to move most
> programs invoked from .desktop into this as systemd services. This
> then means that the actual sessions will become pretty empty, with
> only stubs remaining that trigger services off this user instance of
> systems.
> 

If you do that, you will still need some way to invoke PAM with different service identities otherwise you'll be implementing a pretty severe vulnerability into the system. If all services are authorized by the same PAM service, it amounts to removing the ability for administrators to differentiate which actions a particular user is allowed to perform.

There is definite value in allowing a user to interact with the samba file-sharing daemon on a system without also being allowed to log on interactively to that system. Similarly, just because someone can log onto a system, that doesn't automatically mean it's reasonable for them to be allowed to run automated services when they are not present.

How are you planning on handling these distinctions in this new design? If the answer is polkit, that's it's own set of worms, as polkit rules are notoriously difficult to manage centrally (the FreeIPA and SSSD projects made an attempt several years ago and aborted; and that was _before_ the .pkla -> JS move).

> Lennart
> 
> -- 
> Lennart Poettering, Red Hat