Enforce per-user limits

[KellerFuchs]

• Users are given a limit of 75 processes
• Users are given half-a-CPU-core and 512MB of RAM (waiting on user-${UID}.slice is not templatable systemd/systemd#2556)
• Users cannot interact with devices except API pseudo-devices. (Done in Compartment user sessions using pam_namespace #28)

Given the urgency of this, I will take a lack of (dis)approval as an approval by timeout in 15h30 (2015-12-30, 11:00 UTC).

[ecliptik]

Not as familiar with the systemd changes, but the pam and limits.conf updates look good and should help with limiting abuse.

[KellerFuchs]

Yes. I held back on merging because I found a bug in the systemd changes: it seems user@.service is special enough that something weird goes on with the Slice parameter.
I've been ill and mostly unable to investigate for the past days, though...

[KellerFuchs]

It seems that the issue is pam_systemd(8) (or logind) having user-${UID} hardcoded somewhere ...

[KellerFuchs]

Seems there is already an issue for that: systemd/systemd#2305

[KellerFuchs]

This is stuck waiting on systemd/systemd#2556
The confinement part (DevicePolicy=closed) should be moved to namespace.conf and a script anyway, as systemd doesn't seem to support some equivalent of pam_namespace's umnt_remnt option.

[KellerFuchs]

@hashbang/administrators Sorry for the erroneous PR close.
Somebody reviews and merges?

[daurnimator]

Don't our user ids for public users start at 3000?

Otherwise, why doesn't the 'users' group work?

[daurnimator]

pam_env should remain first to unset any dangerous environmental variables.

[KellerFuchs]

@daurnimator Each user has their own group, the users group is not really a thing.
Also, unless I'm mistaken, no environment variable is currently unset (nor would it matter, since PAM modules shouldn't take config from the environment), but I have no problem with putting pam_env first.

Also, there are some legacy users with UID < 3000:

% getent passwd deleriux
deleriux:*:1019:1019:deleriux:/home/deleriux:/bin/bash

[KellerFuchs]

@ChickenNuggers reviewed too.

[KellerFuchs]

Deployed

[ghost]

@KellerFuchs look at this way of setting per-user CPU and memory limits. Personally I think it is more flexible than templating user-${UID}.slice because, for example, you may load user limits from config file or ask LDAP server.

[daurnimator]

@BerserkerTroll interesting solution: slightly racey (though users will be constrained after the fact, so no issue?), but I think it's as good as we are going to get.

[RyanSquared]

It could also be helpful for the (very long term) plans for allowing users to run "large" jobs - we were planning a system where users could "request" power to run a large job for a time, this could help with it.

[KellerFuchs]

@BerserkerTroll That would be much better done with pam_exec, but yes that could be one option.

[ghost]

@KellerFuchs didn't know about pam_exec.

[daurnimator]

Created #182 to track.

[ghost]

The second task is still not completed?

[KellerFuchs]

@BerserkerTroll Which “second task” ?

[ghost]

@KellerFuchs the second checkbox was unchecked until recently.

[KellerFuchs]

@BerserkerTroll Yes, this has been done in a separate pull request, you are commenting on a change from late 2015