[systemd-devel] pam_systemd.so indirectly calling pam_acct_mgmt

[Jakub Hrozek]

On 10.04.2015 17:31, Lennart Poettering wrote:
> On Fri, 10.04.15 17:20, Jakub Hrozek (jakub.hrozek at posteo.se) wrote:
> 
>> 
>> 
>> On 10.04.2015 17:06, Lennart Poettering wrote:
>> >On Fri, 10.04.15 16:56, Jakub Hrozek (jakub.hrozek at posteo.se) wrote:
>> >
>> >>I'm wondering why does systemd-user call the account stack at all? I can
>> >>understand the session phase, but wouldn't the account phase be already
>> >>checked by whoever was logging in the user (ssh, gdm, ...).
>> >
>> >If "lingering" is turned on we will start the systemd --user instance
>> >also at boot, without the user being logged in. This is accessible via
>> >"loginctl set-linger".
>> >
>> 
>> (You mean enable-linger, right?)
>> 
>> Thanks, this seems to do the trick!
>> 
>> >>And more generally, could we optimize the account phase somewhat on
>> >>the SSSD side so the full access control would not be run? Is there
>> >>some heuristic we can do?
>> >
>> >Well, we need to run throught he PAM hooks for all normal user code we
>> >run, there's really no way around that I fear.
>> >
>> >I mean, sssd can optimize internally, but that doesn't relieve systemd
>> >from calling into PAM...
>> 
>> I see. The optimization in SSSD is tricky, though, b/c as I said, from
>> SSSD's point of view, it's totally different PAM conversation, so SSSD 
>> tries
>> to be on the safe side and run the full thing.
> 
> Well, it kinda *is* a separate conversation. The processes this forks
> off are not part of the user session that logged in on the console,
> and as mentioned, the systemd --user instance might exist without,
> with one or with multiple sessions of the same user being
> around... Also, the lifecycle might be relatively detached from any
> foreground session. it might exist earlier than the first actual
> session, it might exist longer than the last actual session, or it
> might exist precisely as long as the user is logged in... Or in other
> words: sssd is right in considering this a separate session, because
> it effectively is...
> 

I'm sorry to ressurect an old thread but...

...why exactly does systemd-user need to call the account stack for? 
Again, I totally understand session, but account?

Is there a documentation I should read beforehand?