Re: [systemd-devel] Question about propagation of INVOCATION_ID and JOURNAL_STREAM env variables in Desktop Environments
On Wed, 2024-05-22 at 17:42 +0200, Lennart Poettering wrote: > On Mi, 22.05.24 17:13, Nop (ctx...@gmail.com) wrote: > > > Hello folks, > > I have a question about what you guys considers to be the > > right/expect way. > > > > I read documentation a bit about INVOCATION_ID and JOURNAL_STREAM and, to > > me, it feels like those two variables should not be propagated from > > DE. > > What precisely do you mean by "DE"? Most desktop environments these > days use systemd as service manager for per-user services too, and > hence they'll get a properly initialized INVOCATION_ID set for each > service. > > If you use a traditional DE that does not use systemd, then you > shouldn't have set INVOCATION_ID since you are invoked from a PAM > session, not from a system service, hence nothing to clean up. > > Hence, I am not really grokking your question. Either you buy into > systemd or you don't. If you do you should be in the clear and have > valid invocation IDs, and if you don't you should also be clear and > not have the variable set at all. So all should be good? > > > I mean, if I start KDE Plasma, for example, using systemd, it will receive > > an $INVOCATION_ID. Now I start any application by clicking around, it will > > inherit and get the very same $INVOCATION_ID. > > Applications are usually started via systemd too, so no? Unfortunately, not (at least in GNOME), it is only done properly if the application is launched via DBus. The GNOME Shell tries to create a scope, but that is more of a half-assed workaround using some code in gnome-desktop IIRC. And the patch to create scopes for all applications launched by GLib never landed upstream because it was not entirely correct in some corner-cases, IIRC. Anyway, sounds like a simple bug. GNOME/KDE should just probably just remove the INVOCATION_ID variable from their own environment so that it cannot be inherited. Or ensure it is not inherited to a launched application. For GNOME, please file a bug against gnome-shell. There are a few other places that launch applications that could also clear it. Primarily GLib but there might be something in e.g. gnome-session. Benjamin > > If the application happen to be konsole or kitty (terminal > > emulator), it still inherit the variables, so that any command run > > inside this terminal emulator also inherit from it. Feels really > > weird to me, no? > > Graphical terminal apps should really not let INVOCATION_ID leak into > their sub-sessions, they are kinda their own thing then. > > > I checked a bit what gnome is doing and it confused me even more: > > all > > applications inherit the variables but the 'gnome-terminal' filters > > out few > > variables (including those two) so that commands don't have it: > > https://gitlab.gnome.org/GNOME/gnome-terminal/-/blob/master/src/terminal-client-utils.cc#L227 > > Seems it's doing things right then. > > > What is your take on this? At which level the filter should occurs > > if it > > should even occurs at all? > > When you open a new "sub-session" or so, and fork processes off down > the tree, then it might make sense to unset these env vars for them. > > Lennart > > -- > Lennart Poettering, Berlin >
Re: [systemd-devel] Disallowing fingerprint authentication if pam_systemd_home.so needs a password
On Tue, 2022-04-26 at 11:02 +0200, Lennart Poettering wrote: > On Mo, 25.04.22 18:15, Benjamin Berg (benja...@sipsolutions.net) wrote: > > > > So, permitting fingerprint auth while homedir is unlocked might still > > > be worthy though, i.e. for sudo or polkit kind of reauthentication > > > during a running session. But for that kind of stuff I'd probably > > > prefer proper integration with homed. i.e. teach homed native > > > libfprintd support and make it ask for finger auth natively, the same > > > way as we ask for fido2 touch auth or so. (libfprintd is glib/gobject > > > though right? can one sanely and safely dlopen() glib stuff from > > > non-glib stuff? that would be kinda a necessity for us) > > > > Exactly. > > > > Yes, libfprint is GLib/Gio based these days (it is convenient overall, > > and nobody really shouted when I changed it). My assumption is that > > dlopen() should work just fine. Not sure how to verify that though. > > Does one need to initialize the gobject class stuff explicitly then though? > > > That said, would one even want that? We can also continue to go through > > the fprintd DBus API for everything. > > Oh, so are you saying libfprintd is just a wrapper around fprintd dbus > apis? (i assumed it was the other way round: fprintd a service built > around libfprintd apis). Wait, you were completely right. fprintd is a wrapper around libfprint with some added logic for print management[1]. > > After all, we already need that anyway to manage the print database > > (/var/lib/fprint) and to enroll prints. > > Hmm, that print database what precisely does that entail? It contains: * Some metadata about the print: - libfprint driver name - device identifier - username - enrolment date * driver specific print information, which is either: - minutiae information - an identifier referencing a print stored on the device From a technical perspective this is a GVariant blob. > In homed it's kinda nice to monopolize authentication info for an > account inside the JSON user record. we place UNIX password hashes > there, fido2 data, pkcs11 data, ssh keys and so on. It would be great > if we could also put as much of the fprint data in there as we can, so > that the home dirs are self contained and portable between > systems. (under the assumption that enrollments are portable between > systems and devices with same vid/pid?) The "(driver, device_id)" tuple has to match. That will usually be the case for "dumb" devices that send an image. Match-on-chip devices will use a serial number as device ID. > That of course only works if hw even allows that: i.e. does one enroll > fingerprints into some memory inside the hw, or is the enrollment > utimately data stored on disk in /var/lib/fprint? If the latter, can > we supply that data as input to fprintd first, via the D-Bus API? > > > Or would you also want to do enroll from within homed somehow? > > well, we do enrollment inside homed for all other kinds of > authentication, i.e. pkcs11, fido2, password, recovery key. I think it > would be natural to do that there too. > > I am happy to call into fprintd dbus APIs for that, and lead the > operation. > > In my idealized world, homed would talk to fprintd, asking it for > enrollment, then fprintd goes through the enrollment or authentication > process, always informing homed about the steps that it is doing which > we'd propagate back to clients. Once enrollment is complete we'd get > some data back from fprintd which we'd make part of the user > record. And we'd pass that back into fprintd when authenticating > things again. > > That said, we usually prefer storing hashes of secrets rather than > secrets in the user record, if fprint's enrollment are true secrets > which we must supply back, maybe that's not ideal after all... OK, in principle, I think we can store the information in homed. There aren't really any secrets, unless you consider biometric information by itself a secret. With that, we have a few alternatives: 1. Keep storage in fprintd, adding new APIs (including ones for crypto if we ever get that) 2. Use homed as a storage backend for fprintd (no idea if this is possible) 3. Send data to fprintd/libfprint from homed. In that case we could use libfprint directly, it is just a question of convenience. That said, devices tend to have little storage and some are even (intentionally) dumb[1]. So we really want to be able to retrieve a list of all known prints for a system. I am fine with scrapping fprintd/pam_fprintd.so, if homed can take over the tasks. It can probably only be used to authorize e.g. sudo/polkit or unlock the screen. But homed mig
Re: [systemd-devel] Antw: [EXT] Re: Disallowing fingerprint authentication if pam_systemd_home.so needs a password
Hello, On Tue, 2022-04-26 at 10:11 +0300, juice wrote: > On 4/26/22 09:41, Ulrich Windl wrote: > > > Using fingerprint for *authentication* is totally broken concept which > > > should never be allowed. > > Why? Is a PIN any better? > > PIN is much better. You will not be leaving your PIN to any drinking > glass you handle or to doorhandles that you open. People leave > fingerprints all around the place and it has been repeatedly > demonstrated that fingerprints can be easily extracted and replicated to > silicone fingers which can be used to fool fingerprint readers. I expect people here know about the caveats of fingerprints, so I doubt there is a need to explain these basics. I am sure that we could discuss at length in what scenarios the use of fingerprints is beneficial (either by itself or in combination with other methods). But, to be honest, I doubt anyone here is really interested in such a discussion. That said, if you want to start it, you should probably embed your list of caveats into more context and considerations for it to be useful. Benjamin signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] Disallowing fingerprint authentication if pam_systemd_home.so needs a password
On Mon, 2022-04-25 at 17:46 +0200, Lennart Poettering wrote: > On Mo, 25.04.22 17:05, Benjamin Berg (benja...@sipsolutions.net) wrote: > > > > i.e. that wen you enroll a fingerprint you can associate some secret > > > key with it that you pass to the hw. And then you store that secret > > > key also on the host, and whenever you need to authorize a user you > > > ask the fingerprint hw for a finger scan plus some value of your > > > choice and it will return you a HMAC of that value, keyed by the > > > secret you specified during enrollment? > > > > I assume that secret would be stored in the TPM to ensure it is > > safe? > > Well, whether to involve the TPM or not would be later step. I > wouldn't necssarily think too much about that. i.e. it would already > be quite nice if whatever we get from the fingerprint chip could > be used to unlock a LUKS volume. Whether we then stick TPM in the > middle or not is another question. > > > > I think pam_systemd_home.so should simply sit in the PAM stack before > > > the fprint auth so that fprint is never asked? > > > > Wouldn't pam_systemd_home.so try to prompt for the password, if we > > included it in the PAM stack. Even when we just want to unlock the > > session? > > Oh, hmm, I see. That goal is conflicting with another design goal of > systemd-homed though: that we LUKS suspend the home directories on > system suspend, i.e. flush out all cryptographic material when we > suspend. I think that's an absolutely crucial feature in a world where > most people never turn off their laptop, but just suspend it. In fact > homed implements things that way already. Only missing bit is GNOME > here: it would have to move the unlock screen out of the session and > into gdm so that we can safely suspend the user processes before we > suspend the LUKS home dirs. Would love if this would be addressed in > GNOME. Yeah, I remember that we discussed that some time ago. There are a lot of things that are not quite right in the stack to do all of this properly. It all doesn't seem overly complicated, but I expect there are a lot of small changes needed to make it all work. > So, permitting fingerprint auth while homedir is unlocked might still > be worthy though, i.e. for sudo or polkit kind of reauthentication > during a running session. But for that kind of stuff I'd probably > prefer proper integration with homed. i.e. teach homed native > libfprintd support and make it ask for finger auth natively, the same > way as we ask for fido2 touch auth or so. (libfprintd is glib/gobject > though right? can one sanely and safely dlopen() glib stuff from > non-glib stuff? that would be kinda a necessity for us) Exactly. Yes, libfprint is GLib/Gio based these days (it is convenient overall, and nobody really shouted when I changed it). My assumption is that dlopen() should work just fine. Not sure how to verify that though. That said, would one even want that? We can also continue to go through the fprintd DBus API for everything. After all, we already need that anyway to manage the print database (/var/lib/fprint) and to enroll prints. Or would you also want to do enroll from within homed somehow? > That said, adding a switch as you suggest to pam_systemd_home would be > trivial. Internally, if you look at the sources of it, you find the > 'please_authenticate' boolean parameter we pass to acquire_home() > which controls exactly what you are asking for. It currently is true > in the auth PAM stack (thus insisting on reauth even if we already > have an unlocked $HOME), and false in the session/accmgt stacks (where > we only want to unlock if we otherwise can't access $HOME). It would > be a matter of making that configurable via some pam module option, > and then overriding this default in case some other auth module > already succeeded. I'd be happy to review/merge a patch for that ;-) Yup, that does sound simple enough. > (But of course, I'd actually prefer native support for finger print > auth in homed, as mentioned above). Obviously. Benjamin signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] Disallowing fingerprint authentication if pam_systemd_home.so needs a password
On Mon, 2022-04-25 at 16:29 +0200, Lennart Poettering wrote: > On Mo, 25.04.22 15:39, Benjamin Berg (benja...@sipsolutions.net) wrote: > > > > Right now homed supports neither (I think it would make a ton of sense > > > to add though. > > > > > > Note that homed home directories are LUKS-unlocked by the password > > > entered or the secret unlocked by pkcs11/fido2. Thus adding > > > alternative authenticators to homed accounts via just PAM will > > > generally not work, since we must have something key-like (i.e. a > > > password, or data blob from the security token or so) to unlock LUKS > > > with. Not sure what fingerprint login has there? > > > > Fingerprint does not provide any data that could be used for unlocking > > LUKS. So, my take is that we need to skip trying fingerprint > > authentication if the home directory cannot be mounted without a > > secret. > > Hmm, are you sure? I mean, I am sure many fingerprint devices are > basically just photo scanners. But aren't there devices that are a bit > smarter, and can do some cryptography based on local fingerprint auth? > > i.e. that wen you enroll a fingerprint you can associate some secret > key with it that you pass to the hw. And then you store that secret > key also on the host, and whenever you need to authorize a user you > ask the fingerprint hw for a finger scan plus some value of your > choice and it will return you a HMAC of that value, keyed by the > secret you specified during enrollment? I assume that secret would be stored in the TPM to ensure it is safe? So far, we don't have any reader for which we can do anything like that. At one point I implemented the Microsoft SDCP protocol[1]. But unfortunately none of the Fingerprint reader manufacturers have created a driver so far (some devices already support SDCP). That said, I don't think that SDCP by itself is sufficient as the device will simply disclose the ID upon a match[2]. But, you are right with pointing to https://docs.microsoft.com/en-us/windows/win32/secbiomet/sensor-requirements-for-secure-biometrics which describes attaching an additional key to a print. Doing something like that on top of SDCP (or separately?) should be simple in theory. Anyway, for now, we don't have that. And I don't see it happening anytime soon unfortunately. > if so, that would be good enough for us I guess, as we could then use > that unlock some of our own stuff incuding LUKS in the end. > > > > I don't understand the question, I have no idea how fingerprint and > > > PAM currently interact... In fact I don't even have any idea whether > > > fingerprint auth can communicate something we can use as unlock key > > > for LUKS to us, and if PAM can function as a transport for that. > > > > Exactly, fingerprint auth cannot communicate any secret. > > > > The trouble is that we need the password for some things (home > > directory, user keyring). The idea of my previous mail was to query > > pam_systemd_home.so whether the home directory is available and the > > simpler fingerprint authentication method may be acceptable. > > I think pam_systemd_home.so should simply sit in the PAM stack before > the fprint auth so that fprint is never asked? Wouldn't pam_systemd_home.so try to prompt for the password, if we included it in the PAM stack. Even when we just want to unlock the session? Benjamin [1] https://github.com/microsoft/SecureDeviceConnectionProtocol/wiki/Secure-Device-Connection-Protocol [2] Hmm, there is something about credential release (and storing an SID in the database). But, I guess that assume we have an SGX enclave or similar that can be assumed to be secure? https://github.com/microsoft/SecureDeviceConnectionProtocol/wiki/Secure-Device-Connection-Protocol#credential-release signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] Disallowing fingerprint authentication if pam_systemd_home.so needs a password
On Mon, 2022-04-25 at 13:28 +0200, Lennart Poettering wrote: > On Mo, 25.04.22 12:09, Benjamin Berg (benja...@sipsolutions.net) wrote: > > if the home directory needs to be decrypted during login then we really > > need a password for authentication, etc. And, that means that > > fingerprint login must not be used (if we are authenticating to log in > > the user). > > > > I have not looked at pam_systemd_home.so more closely. But, if we need > > the user's password, we need to either immediately return > > PAM_AUTHINFO_UNAVAIL (GDM) or skip fingerprint auth (TTY). > > Hmm, not sure I follow? I don't know how fingerprint flow of control > is. Is this about authentication-by-fingerprint? Or already about > user-selection-by-fingerprint? I was just thinking of authentication-by-fingerprint. Though I don't think it makes a big difference here. > Right now homed supports neither (I think it would make a ton of sense > to add though. > > Note that homed home directories are LUKS-unlocked by the password > entered or the secret unlocked by pkcs11/fido2. Thus adding > alternative authenticators to homed accounts via just PAM will > generally not work, since we must have something key-like (i.e. a > password, or data blob from the security token or so) to unlock LUKS > with. Not sure what fingerprint login has there? Fingerprint does not provide any data that could be used for unlocking LUKS. So, my take is that we need to skip trying fingerprint authentication if the home directory cannot be mounted without a secret. > > My thinking is, that we can easily add an option to pam_systemd_home.so > > so that it returns an error condition telling us whether an > > authentication token is needed or if a specific type of authentication > > is acceptable (e.g. smartcard/fingerprint). This would allow us to > > either jump over the pam_fprintd.so module or create rules to > > immediately error out. > > homed returns to pam_systemd_home.so a relatively descriptive error id > telling it what it needs. i.e. password, a recovery key, a pin, a > hardware token being plugged in and so on. Note that these error ids are > generally not the full truth though. i.e. if homed says "give me a hw > token", then it usually also means "a recovery key is also ok". we > only return the "best" error if you so will, for the "cleanest" way to > login (and that usually is a security token if one is defined, and not > a password, or even recovery key). > > moreover, in homed we might need multiple different security items for > a single authentication to complete. Because of that > pam_systemd_home.so might internally already loop and ask for multiple > pieces of data/actions from the user, and not return control back to > the PAM service in between: it needs to collect these bits and not > lose them because the PAM stack is restarted or so. > > Anyway, so we have these error ids in pam_systemd_home.so, but PAM > doesn't really have an error vocabulary that is precise enough so > that we could propagate this further. > > > Does anyone know what is already possible, or is there someone willing > > to add the required feature to implement it? > > I don't understand the question, I have no idea how fingerprint and > PAM currently interact... In fact I don't even have any idea whether > fingerprint auth can communicate something we can use as unlock key > for LUKS to us, and if PAM can function as a transport for that. Exactly, fingerprint auth cannot communicate any secret. The trouble is that we need the password for some things (home directory, user keyring). The idea of my previous mail was to query pam_systemd_home.so whether the home directory is available and the simpler fingerprint authentication method may be acceptable. To be fair, a simpler approach could be to purely check if the user already has a session (and that the home directory LUKS key is still available). Benjamin PS: So, my naive thought was that we could have an option for pam_systemd_home.so that tests whether a secret is needed to mount the home directory. e.g. auth requiredpam_systemd_home.so secret_available ... auth [success=done default=bad] pam_fprintd.so Assuming we have a user selected. The pam_systemd_home.so rule would: * Return SUCCESS, if the users home directory is mounted or can be mounted with the available secrets * Return AUTHINFO_UNAVAIL, if a further secret is needed Which means the user is not shown the fingerprint option in GDM. signature.asc Description: This is a digitally signed message part
[systemd-devel] Disallowing fingerprint authentication if pam_systemd_home.so needs a password
Hi, if the home directory needs to be decrypted during login then we really need a password for authentication, etc. And, that means that fingerprint login must not be used (if we are authenticating to log in the user). I have not looked at pam_systemd_home.so more closely. But, if we need the user's password, we need to either immediately return PAM_AUTHINFO_UNAVAIL (GDM) or skip fingerprint auth (TTY). My thinking is, that we can easily add an option to pam_systemd_home.so so that it returns an error condition telling us whether an authentication token is needed or if a specific type of authentication is acceptable (e.g. smartcard/fingerprint). This would allow us to either jump over the pam_fprintd.so module or create rules to immediately error out. Does anyone know what is already possible, or is there someone willing to add the required feature to implement it? Benjamin signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] unable to attach pid to service delegated directory in unified mode after restart
HI, On Thu, 2022-03-24 at 12:40 +0100, Felip Moll wrote: > False, the JobRemoved signal returns the id, job, unit and result. To > wait for JobRemoved only needs a matching rule for this signal. The > matching rule can just contain the path. In fact, nothing else than > strings can be matched in a rule, so I may be only able to use the > path. I think you need to add a wildcard match before the job is created (i.e. before StartTransientUnit). Otherwise registering the match rule (using the job's object path) will race with systemd signalling that the job has completed. Benjamin signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] Automatically moving forked processes in a different cgroup based on children's UID
Hi, systemd will not help you with managing the cgroup sub-hierarchy underneath the daemon. I suppose the most generic solution would be something like cgrulesengd for cgroup v2. No idea if something like that exists. I assume you have had a look at https://systemd.io/CGROUP_DELEGATION/#three-scenarios and other parts of that document. And that you are choosing option #2 for good reasons. Managing the cgroup hierarchy is quite simple in principle (mkdir and then a write to cgroup.procs). Or, even better by using CLONE_INTO_CGROUP when creating the processes. It is not that hard to write small daemon that does this. If you want to do so, then you could look into the cgroupify hack[1] that is in uresourced to move each process into its own cgroup. This is done for browsers in Fedora as systemd-oomd always kills an entire cgroup. That said, it is not perfect and you'll need a different logic overall. But it may be a good reference if you want to implement something similar yourself. Having the cgroup management inside apache itself would probably be better overall and may not be much harder. Benjamin [1] https://gitlab.freedesktop.org/benzea/uresourced/-/blob/master/cgroupify/cgroupify.c Startup works by installing a small template service https://gitlab.freedesktop.org/benzea/uresourced/-/blob/master/data/user/cgroup...@.service.in and a simple drop-in unit for every service that should be managed https://gitlab.freedesktop.org/benzea/uresourced/-/blob/master/data/user/cgroupify.service On Sat, 2022-01-01 at 16:41 -0500, Wadih wrote: > Hi, > > I've been using apache2-mpm-itk with cgrulesengd in cgroupv1 to > automatically classify the child processes that apache2-mpm-itk > spawns when servicing web requests for different vhosts for about 3 > years, and it's been working great, when a vhost starts using up too > much CPU/RAM, oom killer takes care of that specific vhost and leaves > the others alone, as well as the parent process. > > I'm now preparing to move to Debian 11 as part of my yearly updates, > and I'm finding out that I need to use cgroup v2 now. So I'm trying > to bring my resource control solution to the new world. > > When I create my e.g. /etc/systemd/system/user- > UID.slice.d/override.conf with the resource controls for that user, > they don't apply to the forked processes, as cgrulesengd used to be > able to do, as I am confirming with systemd-cgls. Instead, the parent > and all its children all still belong to the same apache2.service > slice. Which makes sense since it wasn't systemd that spawned the > child processes. > > Is there a way to automatically classify child processes of a process > in a different cgroup than the spawning process with systemd based on > the children's new UID? I know apache2-mpm-itk calls setuid() on its > children, so we would have to somehow hook on that. > > By default, the processes are now all in : > > system.slice/apache2.service > > I'd like to have the child processes that apache2-mpm-itk spawns go > under their respective user, e.g. > > system.slice/apache2.service/vhosts/%UID% > > And then I would set a memory limit of 1G on > system.slice/apache2.service/vhosts > > Then when the sum of the memory usage of the vhosts goes above 1G, > oom killer will choose the biggest offending group under > system.slice/apache2.service/vhosts/ and terminate that group, > without touching the others nor the parent process. I've been able to > do this with cgrulesengd and cgconfigparser for 3 years, it's been > rock solid. I'm trying to bring that to the new systemd world. > > Would the only solution for me to create a daemon which monitors for > setuid() calls of the parent apache process, and classify the > children as per the new setuid user? > > Or perhaps, I think root parent processes spawning specific UID > children is a common security practise, perhaps there should be > something in systemd out of the box for classifying the children > under their respective cgroups? > > If my only solution is to create a daemon which monitors for setuid() > I'll do it, although I've never done it before, not sure where I'd > have to start. Any guidance would be great! > > Thank you so much, > > Wadih Maalouf signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] How to correctly use memory controls (MemoryLow) on unified hierarchy system?
On Fri, 2021-05-21 at 20:14 +0300, Andrei Borzenkov wrote: > On 21.05.2021 17:07, Benjamin Berg wrote: > > [SNIP] > > Yes, you need to set it on all ancestors, and the documentation > > mentions this: > > > > """ > > For a protection to be effective, it is generally required to > > set a corresponding allocation on all ancestors, which is > > then distributed between children (with the exception of the > > root slice). Any MemoryMin= or MemoryLow= allocation that is > > not explicitly distributed to specific children is used to > > create a shared protection for all children. As this is a > > shared protection, the children will freely compete for the > > memory. > > """ > > > > OK, it is in upstream now, was not in my version and I did not pay > attention to web page. Sorry. Ah, true, they were updated not too long ago. > I guess I expected systemd to somehow handle it, given that it knows > all the settings, knows exact hierarchy and is the sole master of > cgroup tree. I think it is a bit of a conundrum. Automatic handling would be neat, but it also does not make sense that protections further up in the hierarchy could increase indefinitely. A somewhat ugly corner case are the automatically created slice units for template services. Here the user will need to explicitly configure a sane limit on the parent slice unit. Benjamin signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to correctly use memory controls (MemoryLow) on unified hierarchy system?
Hi, On Fri, 2021-05-21 at 15:25 +0300, Andrei Borzenkov wrote: > systemd offers MemoryLow for an individual units. It actually sets > memory.low cgroup attribute, so this is OK. The problem is according to > kernel dcouemtation, memory.low is limited by value set in parent > cgroup and all parent cgroups have memory.low=0: > > /sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/gnome- > shell-wayland.service/memory.low:536870912 > /sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/memory.low: > 0 > /sys/fs/cgroup/user.slice/user-1001.slice/memory.low:0 > /sys/fs/cgroup/user.slice/memory.low:0 > > which implies setting on lead cgroup has no effect. > > Is it necessary to explicitly set it on every ancestor? There is no > clarification in systemd documentation and value is applied without any > warning. Yes, you need to set it on all ancestors, and the documentation mentions this: """ For a protection to be effective, it is generally required to set a corresponding allocation on all ancestors, which is then distributed between children (with the exception of the root slice). Any MemoryMin= or MemoryLow= allocation that is not explicitly distributed to specific children is used to create a shared protection for all children. As this is a shared protection, the children will freely compete for the memory. """ Depending on the kernel versions there may be some other caveats: """ Units may have their children use a default "memory.min" or "memory.low" value by specifying DefaultMemoryMin= or DefaultMemoryLow=, which has the same semantics as MemoryMin= and MemoryLow=. This setting does not affect "memory.min" or "memory.low" in the unit itself. Using it to set a default child allocation is only useful on kernels older than 5.7, which do not support the "memory_recursiveprot" cgroup2 mount option. """ You need to configure it correctly in various locations. Personally, I would suggest taking a look at uresourced[1]. It will correctly set a configurable memory protection, enables some other cgroup features and tracks the currently active user. Fedora is shipping it by default and it appears to work well there. Benjamin [1] https://gitlab.freedesktop.org/benzea/uresourced and https://lwn.net/Articles/829567/ signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Environment variables are not sanitized when a graphical session dies
Hi, On Tue, 2021-04-06 at 19:02 +0300, Arseny Maslennikov wrote: > [SNIP] > The above was a brainstormed reproducer; I did actually encounter > this > kind of bug IRL a couple of times this way. > I'd used GDM to log in to GNOME on Xorg, then logged out, then logged > in > to Sway (a Wayland compositor/window manager), and some apps e. g. > telegram-desktop malfunction because they infer they're running in > GNOME > from the GNOME-specific environment vars that were not unset on > logout > from GNOME: > > % systemctl --user show-environment | grep -i GNOME > DESKTOP_SESSION=gnome > GDMSESSION=gnome > GNOME_DESKTOP_SESSION_ID=this-is-deprecated > XDG_CURRENT_DESKTOP=GNOME > XDG_MENU_PREFIX=gnome- > XDG_SESSION_DESKTOP=gnome > _=/usr/bin/gnome-session > > The _, most likely set by a unix shell, is especially funny. :) Yes, this is a problem. The _ is really not great, we could add it to the ignore list. > The leaked values of XDG_CURRENT_DESKTOP and XDG_SESSION_DESKTOP also > break xdg-desktop-portal in the new session as well, etc. In short, > this is not robust enough and can break in a multitude of ways, most > of them unknown a priori. > > To sum it up, if we use the user manager environment store this way, > there should be a way to automatically remove session-specific > environment vars from systemd --user when the respective session is > terminated. > > Possible ways to fix: > * Per-session unit managers: this approach was discussed previously > and > deemed hard to implement; unclear relationships between session > units > and user units. > * Tie the systemd--user environment store entries to session IDs. > When logind emits org.freedesktop.login1.Manager.SessionRemoved on > /org/freedesktop/login1, remove environment variables tied to that > session. > * user-specific environment stores for graphical sessions in logind > and > an opt-in mechanism (e. g. UseSessionEnvironment=yes) in unit files > to > use them, API to modify/flush them (on the bus and via loginctl), > autoflush when the graphical session dies. > Not too hard to implement, basically 1 hash table per user. > A session starter would do > `loginctl import-environment XDG_CURRENT_DESKTOP' > instead of > `systemctl import-environment XDG_CURRENT_DESKTOP' > If I recall correctly, user managers already requires logind, so > that's not a problem. > So, what I had been thinking to do in GNOME at one point (but never did), is to write a file in $XDG_RUNTIME_DIR of all variables that were set by GNOME (possibly containing the old values). Then, at logout, unset these variables (or reset to old values). In GNOME, everything is going through the gnome-session binary, and it would be quite simple to implement this in a safe manner. > I'm not opposed to writing a patch to fix this or just filing an > issue report, but wanted to discuss the general direction we'd like > to take here first. Hmm, what I think would be helpful is a mechanism to restart services after the session has adjusted the environment. Otherwise these services will not pick up changes in the environment; usually not a big deal, but it can for example cause issues when the user changes their language and e.g. pulseaudio/pipewire are not restarted even though the user has logged out for a short time. Maybe we could have a feature in systemd that causes services to restart when certain variables in their environment block have changed? Benjamin signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Still confused with socket activation
On Thu, 2021-02-04 at 22:16 +0300, Andrei Borzenkov wrote: > 03.02.2021 22:25, Benjamin Berg пишет: > > Requires= actually has the difference that the unit must become > > part of > > the transaction (if it is not active already). So you get a hard > > failure and appropriate logging if the unit cannot be added to the > > transaction for some reason. > > > > Oh, I said "documented" :) systemd documentation does not even define > what "transaction" is. You really need to know low level implementation > details to use it in this way. > > But thank you, I missed this subtlety. Of course another reason could be > stop behavior. Oh, good point! I really had not been considering the implication on stop behaviour. :) Benjamin > > > Care to show more complete example and explain why Wants does not > > > work in this case? > > > > Wants= would work fine. I think it boils down to whether you find > > the > > extra assertions useful. The Requires= documentation actually > > suggests > > using Wants= exactly to avoid this. > > > > Benjamin > > > > signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Still confused with socket activation
On Thu, 2021-02-04 at 13:07 +0100, Reindl Harald wrote: > Am 04.02.21 um 12:46 schrieb Benjamin Berg: > > On Wed, 2021-02-03 at 16:43 +0100, Reindl Harald wrote: > > > seriously - explain what you expect to happen in case of > > > > > > Requires=a.service > > > Before=a.service > > > > > > except some warning that it's nonsense > > > > So, one way I used it is as ExecStartPost= equivalent for a .target > > unit. i.e. pull in a Type=oneshot service once a target has become > > active in order to execute a simple command > > "Requires=a.service" combined with "Before=a.service" is > contradictory - > don't you get that? Your statements will not become more informed by repeating them. It looks to me like you are interpreting Requires= incorrectly. Of course, one can see a contradiction in saying "B requires A in order to run" and then also saying "start A after B is ready". But systemd considers requirements and ordering as two independent problems. As such "Requires=A" only means something like "unit A must be added to the transaction together with B". A statement that does not imply ordering. Yes, this is a a very logical/mathematical meaning which may not be what you intuitively expect. And it does have the unfortunate side effect of sometimes confusing people and they forget to add a needed After= that they thought was implied. But, it is well defined what happens when combining Requires= with Before=. There is no contradiction. Benjamin signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Still confused with socket activation
On Wed, 2021-02-03 at 16:43 +0100, Reindl Harald wrote: > seriously - explain what you expect to happen in case of > > Requires=a.service > Before=a.service > > except some warning that it's nonsense So, one way I used it is as ExecStartPost= equivalent for a .target unit. i.e. pull in a Type=oneshot service once a target has become active in order to execute a simple command. Benjamin signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Still confused with socket activation
On Wed, 2021-02-03 at 20:47 +0300, Andrei Borzenkov wrote: > 03.02.2021 00:25, Benjamin Berg пишет: > > On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote: > > > 02.02.2021 17:59, Lennart Poettering пишет: > > > > > > > > Note that Requires= in almost all cases should be combined with > > > > an > > > > order dep of After= onto the same unit. > > > > > > Years ago I asked for example when Requires makes sense without > > > After. > > > Care to show it? I assume you must have use case if you say "in > > > almost all". > > > > In the GNOME systemd units there are a few places where a Requires= > > is > > combined with Before=. > > > > This is functionally completely equivalent to simply using > Wants+Before. > At least as long as you rely on *documented* functions. Requires= actually has the difference that the unit must become part of the transaction (if it is not active already). So you get a hard failure and appropriate logging if the unit cannot be added to the transaction for some reason. > Care to show more complete example and explain why Wants does not > work in this case? Wants= would work fine. I think it boils down to whether you find the extra assertions useful. The Requires= documentation actually suggests using Wants= exactly to avoid this. Benjamin signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Still confused with socket activation
On Wed, 2021-02-03 at 08:00 +0100, Reindl Harald wrote: > > > Am 02.02.21 um 22:25 schrieb Benjamin Berg: > > On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote: > > > 02.02.2021 17:59, Lennart Poettering пишет: > > > > > > > > Note that Requires= in almost all cases should be combined with > > > > an > > > > order dep of After= onto the same unit. > > > > > > Years ago I asked for example when Requires makes sense without > > > After. > > > Care to show it? I assume you must have use case if you say "in > > > almost all". > > > > In the GNOME systemd units there are a few places where a Requires= > > is > > combined with Before= > > sounds like complete nonsense > > you can not require something at your own to be there but on the other > hand start before it - at least by common sense The units are indeed non-trivial. I have put in a lot of effort to find a solution that both works and is robust in various failure modes. It may well be that there is a better approach with similar properties. But, session login and logout(!) is not quite as trivial as one could hope for unfortunately (backward compatibility and workarounds add some complexities). So, I would love to be educated on how to simplify all this while still catching the various corner cases. But in order to convince me, you'll need to make a more concrete suggestion and explain its properties. Benjamin signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Still confused with socket activation
On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote: > 02.02.2021 17:59, Lennart Poettering пишет: > > > > Note that Requires= in almost all cases should be combined with an > > order dep of After= onto the same unit. > > Years ago I asked for example when Requires makes sense without > After. > Care to show it? I assume you must have use case if you say "in > almost all". In the GNOME systemd units there are a few places where a Requires= is combined with Before=. Benjamin signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: Memory in systemctl status
On Wed, 2020-09-30 at 11:04 +0200, Ulrich Windl wrote: > > > > Reindl Harald schrieb am 30.09.2020 um 10:56 in > Nachricht : > > > Am 30.09.20 um 09:06 schrieb Ulrich Windl: > > > > my webserver is killed because it served at monday, tuesday, thursday > > > > and friday 4 different files with 2 GB? > > > > > > cgroups is for limiting resources, not for killing processes AFAIK > > > > [Service] > > MemoryMax=4G > > > > would call OOM killer > > Are you sure? I thought OOM is called when the _system_ memory is exhausted. > IMHO any memory allocation request to the process will be denied, but the > process wouldn't be killed. But agreed, I didn't track the cgroups changes in > the last few years. I think you can assume that the OOM killer will kick in rather than the allocation request being denied. This option does cap the amount system memory that is used for the cgroup. So if memory cannot be reclaimed (e.g. swapped out, file backed) then the OOM killer will run within the cgroup. As I understand it, what Reindl is looking for is seeing and limiting the amount of resident anonymous pages that the cgroup has rather than its real memory use. Benjamin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
On Mon, 2020-09-28 at 11:37 +0200, Reindl Harald wrote: > > Am 28.09.20 um 11:19 schrieb Benjamin Berg: > > > if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it > > > when the > > > caches are accounted in that context > > > > No, the kernel kicks in and reclaims memory at that point. Which can > > mean either swapping or just dropping caches. > > caches have *nothing* to do with the service itself They really do. Try running multiple concurrent services that are actually competing for limited memory resources. Caches are only boring as long as you have plenty of extra memory available so that there is no competition for it. > > It really sounds to me like ulimit fits better what you are trying to > > do. That is available through Limit*=, see systemd.exec. > > hell first i want a output in "systemctl status whatever" which is true > and don't contain a ISO image downloaded by someone two days ago The output does not match your expectation. But that really doesn't mean it is false. If you really want more detail, then have a look at /sys/fs/cgroup/system.slice/httpd.service/memory.stat but /sys/fs/cgroup/system.slice/httpd.service/memory.current really is important. It is the one that tells you how much system memory is used by the kernel to keep the service running. Benjamin > not more and not less > > httpd don't use 8.7 GB RAM - period > > the only interesting memory is RES of all the processes > > my Firefox on the desktop don't use 32 GB RAM even when VIRT shows that > and even if the latest download of a 10 GB file is somewhere in the OS > caches in case it's opened later - it's *free* memory > > Main PID: 713 (httpd) > Tasks: 16 (limit: 1024) >Memory: 8.7G > CPU: 2h 24min 14.348s >CGroup: /system.slice/httpd.service >├─713 /usr/sbin/httpd -D FOREGROUND >├─2435242 /usr/sbin/httpd -D FOREGROUND >├─2435243 /usr/sbin/httpd -D FOREGROUND >├─2435931 /usr/sbin/httpd -D FOREGROUND >├─2435942 /usr/sbin/httpd -D FOREGROUND >├─2435944 /usr/sbin/httpd -D FOREGROUND >├─2435947 /usr/sbin/httpd -D FOREGROUND >├─2435948 /usr/sbin/httpd -D FOREGROUND >├─2435952 /usr/sbin/httpd -D FOREGROUND >├─2435954 /usr/sbin/httpd -D FOREGROUND >├─2435960 /usr/sbin/httpd -D FOREGROUND >├─2435966 /usr/sbin/httpd -D FOREGROUND >├─2435968 /usr/sbin/httpd -D FOREGROUND >├─2435969 /usr/sbin/httpd -D FOREGROUND >├─2435970 /usr/sbin/httpd -D FOREGROUND >└─2435972 /usr/sbin/httpd -D FOREGROUND > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
On Mon, 2020-09-28 at 10:43 +0200, Reindl Harald wrote: > > Am 28.09.20 um 10:37 schrieb Tomasz Torcz: > > On Mon, Sep 28, 2020 at 10:08:15AM +0200, Reindl Harald wrote: > > > Am 27.09.20 um 23:39 schrieb Benjamin Berg: > > > > > > > however, that value makes little to no sense and if that's the > > > > > > > same > > > > > > > value as accounted for "MemoryMax" it's plain wrong > > > > But it does make sense. File caches are part of the working set of > > > > memory that a process needs. Setting MemoryMax=/MemoryMin= > > > > limits/guarantees the size of this working set. These kinds of limits > > > > or protections would be a lot less meaningful if caches were not > > > > accounted for. > > > > > > sorry but that is complete nosense > > > > > > caches are freed as soon whatever process asks for RAM and so they are > > > *not* part of the working set > > > > > > my webserver is killed because it served at monday, tuesday, thursday > > > and friday 4 different files with 2 GB? > > > > Why "killed", you wrote yourself caches are freed. So are they freed > > or aren't they? > > if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it when the > caches are accounted in that context No, the kernel kicks in and reclaims memory at that point. Which can mean either swapping or just dropping caches. > why should the caches be freed as long as no other process allocates memory? Because it means different parts of the system are properly isolated from each other. > "These kinds of limits or protections would be a lot less meaningful if > caches were not accounted for" is nonsense - os caches are part of the > VFS and have nothing to do with protect from a process allocating 10 GB > private memory which can't be freed other than swap it out It really sounds to me like ulimit fits better what you are trying to do. That is available through Limit*=, see systemd.exec. Benjamin signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Memory in systemctl status
On Sun, 2020-09-27 at 17:45 +0200, Reindl Harald wrote: > > Am 27.09.20 um 14:08 schrieb Greg KH: > > On Sun, Sep 27, 2020 at 01:41:33PM +0200, Reindl Harald wrote: > > > Memory: 8.6G > > > > > > looks like there is a large part of os-caching included where i wonmder > > > how that's done because a file can be read by muliple processes / > > > services and is hopfefully only once cached I believe it is generally accounted against the cgroup that caused it to be read into main memory. The cgroup documentation probably has more details. > > > however, that value makes little to no sense and if that's the same > > > value as accounted for "MemoryMax" it's plain wrong But it does make sense. File caches are part of the working set of memory that a process needs. Setting MemoryMax=/MemoryMin= limits/guarantees the size of this working set. These kinds of limits or protections would be a lot less meaningful if caches were not accounted for. Benjamin > > > [root@arrakis:~]$ free > > > totalusedfree shared buff/cache > > > available > > > Mem: 15Gi 2.2Gi 585Mi 309Mi12Gi > > >12Gi > > > Swap:0B 0B 0B > > > > The kernel does this, it's nothing to do with systemd or anything else. > > > > You can get "back" that memory for a short while if you really want it > > by doing: > > echo 3 > /proc/sys/vm/drop_caches > > > > For more details, see https://www.linuxatemyram.com/ > > you completly miss the point and should not cut in the middle of a post! > > Memory: 8.6G > > *no* httpd don't consume 8.6GB RAM > > the question is *why* systemd takes the os-cache into account of the > memory a service is using > > [root@arrakis:~]$ systemctl status httpd.service > ● httpd.service - Apache Webserver >Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; > vendor preset: disabled) > Drop-In: /etc/systemd/system/httpd.service.d >└─lockdown.conf >Active: active (running) since Sun 2020-09-20 07:53:39 CEST; 1 weeks > 0 days ago > Process: 1935633 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful > (code=exited, status=0/SUCCESS) > Main PID: 713 (httpd) > Tasks: 17 (limit: 1024) >Memory: 8.6G > CPU: 2h 8min 5.442s >CGroup: /system.slice/httpd.service >├─713 /usr/sbin/httpd -D FOREGROUND >├─2151772 /usr/sbin/httpd -D FOREGROUND >├─2151803 /usr/sbin/httpd -D FOREGROUND >├─2151805 /usr/sbin/httpd -D FOREGROUND >├─2152130 /usr/sbin/httpd -D FOREGROUND >├─2152132 /usr/sbin/httpd -D FOREGROUND >├─2152188 /usr/sbin/httpd -D FOREGROUND >├─2152189 /usr/sbin/httpd -D FOREGROUND >├─2152199 /usr/sbin/httpd -D FOREGROUND >├─2152211 /usr/sbin/httpd -D FOREGROUND >├─2152213 /usr/sbin/httpd -D FOREGROUND >├─2152214 /usr/sbin/httpd -D FOREGROUND >├─2152215 /usr/sbin/httpd -D FOREGROUND >├─2152217 /usr/sbin/httpd -D FOREGROUND >├─2152220 /usr/sbin/httpd -D FOREGROUND >├─2152756 /usr/sbin/httpd -D FOREGROUND >└─2152886 /usr/sbin/httpd -D FOREGROUND > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shut down system after all sshd instances terminate
Hi,
you can use Wants= to pull in another service, and then use
StopWhenUnneeded= to make that shutdown after the last sshd@.service
disappears.
So, I guess something like the below:
sshd@.service drop-in:
```
[Unit]
Wants=sshd-running.service
```
sshd-running.service
```
[Unit]
StopWhenUnneeded=true
[Service]
Type=oneshot
RemainAfterExit=yes
# Not sure if SuccessAction works
# probably does but you might need a dummy ExecStart=/sbin/true then
ExecStop=systemctl poweroff
#SuccessAction=exit
```
Benjamin
On Sun, 2020-08-23 at 16:02 +0100, Daan De Meyer wrote:
> Nvm, that wouldn't work at all because inhibitor locks are ignored if
> the user is privileged enough.
>
> So getting the system to shut down after an sshd instance exits is
> easy enough with SuccessAction. Waiting for all sshd instances to
> finish before shutting down turns out to be extremely hard. I've been
> trying out stuff for multiple hours now and haven't come even close.
> There definitely seems to be at least a documentation issue here so
> if
> there's a solution I intend to make a PR that clarifies this
> somewhere
> in the official documentation.
>
> My last (failed) attempt is this (sshd@.service) :
>
> ```
> [Unit]
> Description=SSH Server for {args.devserver_name} devserver
> After=network.target
> After=exit.target
>
> [Service]
> ExecStart=/usr/sbin/sshd -i
> KillMode=none
> TimeoutStopSec=infinity
> StandardInput=socket
> SuccessAction=exit
> FailureAction=exit
> ```
>
> When an ssh connection comes in, an instance of this template is
> started to handle the connection. Now, what I want to achieve is that
> when all instances of this sshd template exit after at least one
> instance has started, the system shuts down.
>
> Daan
>
> On Sun, 23 Aug 2020 at 14:47, Daan De Meyer > wrote:
> > Hi,
> >
> > After following
> > http://0pointer.de/blog/projects/socket-activated-containers.html
> > which details how to set up a socket activated container, I'm
> > looking
> > into ways to have the container automatically shut down when the
> > last
> > ssh connection terminates.
> >
> > My idea was to have each sshd instance take an inhibitor lock (the
> > blocking kind) that prevents poweroff and make each sshd instance
> > pull
> > in poweroff.target. The problem is that the inhibitor documentation
> > mentions that poweroff operations will fail if a blocking inhibitor
> > lock is taken. For this to work, I need poweroff.target to wait
> > indefinitely until all locks are released. Is this possible at the
> > moment?
> >
> > Any other suggestions on how to achieve this are appreciated as
> > well.
> >
> > Cheers,
> >
> > Daan
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] protecting sshd against forkbombs, excessive memory usage by other processes
Hi, I would suggest trying the following: * Set a MemoryLow allocation * Enable the CPU cgroup controller For the first, it'll make sense to set MemoryLow= on system.slice and also setting DefaultMemoryLow= or MemoryLow= on sshd.service. Otherwise things might be somewhat unexpected for now, see https://github.com/systemd/systemd/pull/16559 I guess one could also do something similar for user-0.slice. The second part ensures CPU is allocated to users fairly, meaning that the user-X.slice's are competing against each other, rather than the individual processes. This will effectively give the root login and SSH service a higher CPU priority in relation to the fork bomb. You can do this by setting CPUWeight=100 on user-.slice. It'll also result in system.slice and user.slice competing for CPU at eye level. Benjamin On Wed, 2020-08-12 at 12:57 +0900, Tomasz Chmielewski wrote: > I've made a mistake and have executed a forkbomb-like task. Almost > immediately, the system became unresponsive, ssh session froze or > were > very slow to output even single characters; some ssh sessions timed > out > and were disconnected. > > It was not possible to connect a new ssh session to interrupt the > runaway task - new connection attempt were simply timing out. > > SSH is the only way to access the server. Eventually, after some 30 > mins, the system "unfroze" - but - I wonder - can systemd help > sysadmins > getting out of such situations? > > I realize it's a bit tricky, as there are two cases here: > > 1) misbehaving program is a child process of sshd (i.e. user logged > in > and executed a forkbomb) > > 2) misbehaving program is not a child process of sshd (i.e. some > system > service is using a lot of resources) > > > Given that - how can we tune systemd so that system admin is almost > always able to log in via a new SSH connection, in both cases > outlined > above? My usage case assumes user error rather than a malicious > system > resource usage. > > > > Tomasz Chmielewski > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
