[systemd-devel] [PATCH] cgroups: chown user slices
lennart at poettering.net
Thu Jul 11 06:52:26 PDT 2013
On Wed, 10.07.13 20:07, Kok, Auke-jan H (auke-jan.h.kok at intel.com) 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
> > user at .service to the specific user. That should solve the issue. (Note
> > that this means systemd --user will only work when run from
> > user at .service, 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 user at 1000.service 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 user at .service will be created. After the user logs out fully
(i.e. the last of his scopes is gone) the slice and user at .service
instance is removed too.
If a user has lingering enabled then the slice and user at .service 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 user at .service 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 user at .service 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 Poettering - Red Hat, Inc.
More information about the systemd-devel