On Fri, 2015-05-01 at 11:46 +0200, Tomasz Torcz wrote: > On Fri, May 01, 2015 at 09:46:26AM +0100, Colin Guthrie wrote: > > Stephen Gallagher wrote on 30/04/15 14:04: > > > On Thu, 2015-04-30 at 15:01 +0200, Lennart Poettering wrote: > > > > On Thu, 30.04.15 08:54, Stephen Gallagher ([email protected]) > > > > > > > > wrote: > > > > > > > > > Does set-linger persist across reboots? > > > > > > > > Yes it does. When a systemd is booted up with a user that has > > > > lingering on this means that his [email protected] instance is > > > > invoked at > > > > boot, without waiting for any login. > > > > > > > > > > One last question, Lennart: what is the primary use-case for the > > > linger feature? When is it expected that users would want to use > > > it? > > > > There are lots of potential uses. > > > > e.g. a user may want to run their irssi IRC client at all times > > (connecting into it via screen or via proxy etc). > > I'm using it primarly for two things: > 1) having user services (like dropbox) run even when I'm not logged > in > 2) do some periodic tasks as user; systemd timers are more flexible > than > cron >
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?
signature.asc
Description: This is a digitally signed message part
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
