On Wed, 10.07.13 20:07, Kok, Auke-jan H ([email protected]) wrote: > >> + r = cg_path_get_owner_uid(path, &uid); > >> + if (r < 0 && r != -ENOENT) > >> + return r; > >> + > >> + if (uid != (uid_t) -1) > >> + chown(fs, uid, (gid_t) -1); > >> + > > > > systemd in git will now grant access to the cgroup subtree in > > [email protected] to the specific user. That should solve the issue. (Note > > that this means systemd --user will only work when run from > > [email protected], as access to the cgroup tree is *not* granted for normal > > sessions directly.) > > can you elaborate what "normal" sessions are? Are we talking about > `PAMName=systemd-shared` being the part that distinguishes them?
So, when somebody logs in now, let's say via "ssh", then ssh goes through PAM to register the new session. pam_systemd talks to logind as part of that to make sure it is tracked by it. logind then does three things: if this is the first login by the user, it will create a slice unit for him, and instantiate [email protected] for him inside that slice. It will then create a scope unit for the PAM client, and return. After the SSH login there will hence be three units for the user: a scope (for the actual session), a service (for the user systemd instance) and a slice (wrapping it all). When the user then logs in a second time, he will get another scope within the existing slice, and no additional [email protected] will be created. After the user logs out fully (i.e. the last of his scopes is gone) the slice and [email protected] instance is removed too. If a user has lingering enabled then the slice and [email protected] are instantiated at boot time already, i.e. they are not reference counted by the session scopes. Now, since we cannot run user code without having set up PAM for it first [email protected] will also go through PAM, however, it will be shortcut in pam_systemd, so that it does not create a logic loop in logind. And yeah, this instance is recognized by the pam service name as set with PAMName=. Only [email protected] will get write access to its own cgroup subtree. This is a good thing, since that way we can be sure that only systemd' own code gets write access to the cgroupfs tree, and no other code. Makes some sense I hope? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
