On Wed, 29.10.14 21:08, Lutz Vieweg ([email protected]) 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@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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
