[systemd-devel] Commands started after "su - username" do not obey "systemctl set-property user.slice MemoryLimit=..."

[Lennart Poettering]

On Wed, 29.10.14 21:08, Lutz Vieweg (lvml at 5t9.de) wrote:

> Hi,
> 
> I configured a CentOS 7 to limit the amount of memory any single
> interactive user can use by setting:
> 
> >systemctl set-property user.slice MemoryLimit=60G
> 
> and excepted "root" to use a less strict limit:
> 
> >systemctl set-property user-0.slice MemoryLimit=120G
> 
> Works so far, but there's a catch: Some times, "root"
> wants to impersonate some user to interactively start
> some software on behalf of that user.
> 
> Yet, when root uses "su - username" to change the user,
> no "user-xxx.slice" is created, not even a new "session"
> below "user-0.slice" is created, causing the wrong
> MemoryLimit to be applied:
> 
> >systemd-cgls
> >└─user.slice
> >  ├─user-0.slice
> >...
> >  │ └─session-18.scope
> >  │   ├─17570 sshd: root at pts/1
> >  │   ├─17572 -bash
> >  │   ├─19514 bash
> >  │   ├─19884 su - johndoe
> >  │   ├─19885 -bash
> >  │   ├─20395 ./memory_hog ...
> 
> How can I configure that processes started as a certain
> user honor the user.slice limit, regardless of whether
> the user used "ssh" to log in, or whether just "root"
> was using "su" to become that user?

Using "su" doesn't really open a new session, it really just changes
the numeric UID, and very few other things. It does not create a new
bus, doesn't pass access to the audio stack, does not create a new
tty, no new XDG_RUNTIME_DIR or anything else. It's a mix and match you
get between the old user and the new user, and part of that is that no
new session is registered by logind, and hence no resources are
applied.

By using "su" you basically tell the system that you want to quickly
and temporarily change your uid, but *without* doing a full new login,
hence staying within your old session. Hence this is what you get...

Lennart

-- 
Lennart Poettering, Red Hat