Nixpkgs: slock: cannot disable the out-of-memory killer for this process

[ericsagnes]

Hi,

Running slock as a normal user return the following error message:

cannot disable the out-of-memory killer for this process

Running it as root or with sudo lock the screen as expected so it might be a permission issue.

• NixOS using unstable channel
• version: slock 1.2
• Store hash: 51aw7a7l3lv4gkryxab3z1fi4p2xrxl8-slock-1.2

[lethalman]

Really, a screen lock need to be removed from the OOM? I would like to understand the reason of this software to remove itself from the OOM killing...

[vcunat]

It still works, right? I'm not sure regular users should have a permission (by default) to disable OOM killer for processes...

The need for that is more of an upstream question. IMHO a reasonable OOM killer seems rather unlikely to kill something that uses very little memory (a screen locker should). Otherwise, a different user might try to unlock by exhausting memory, and I imagine many DOS-type attacks can also exhaust memory, perhaps even without authentication.

[lethalman]

Yes it just doesn't make sense for a screen lock to disable OOM killer. Disabling OOM killer only makes sense for processes such as sshd.

[domenkozar]

see https://groups.google.com/forum/#!topic/wmii/WnOzQIolWqw

[lethalman]

Well, it's not one of the best descriptions honestly for that patch. Also if it fails to set the oom adjustement it should not quit, rather tell some warning. And I don't know of any other screen lock disabling the oom. Hence I consider that piece of code broken.

[ericsagnes]

see https://groups.google.com/forum/#!topic/wmii/WnOzQIolWqw

The patches referred in this thread have been committed to their git repository and are present in the 1.2 release.

In the upstream slock master, there is an unreleased commit mentioning oom, Slightly safer OOM killer disablement in linux.
I tried to apply it, but it didn't help.

As a note, on archlinux slock is working fine and they don't seem to apply any particular patch.

As there are alternatives working fine like slimlock, it is not a big deal.
But it might be more user friendly to flag slock as broken until a solution is found?

[peti]

IMHO, it makes perfect sense for slock to try and protect itself against OOM. I use slock to lock my machine at work, and that machine performs expensive computations while I'm away (but logged in). If it ran out of memory and if the kernel thus killed slock, then my active session would suddenly be open for everyone who walks past my office -- and that session contains a running gpg-daemon with cached signature keys that give you access to virtually every other machine I work on including login credentials as root. In other words, if slock is suddenly killed on my machine, then that would be _bad news_.

I solve this issue by defining the following bits in my global configuration.nix:

environment.systemPackages = with pkgs; [ slock ];
security.setuidPrograms = [ "slock" ];

[lethalman]

@peti pretty sure it's a kind of configuration you can do on your behalf as system configuration, and not something slock has to do by itself. And anyway, it should really be a warning and not a fatal.

[peti]

@lethalman, that is possible, of course. I don't know much about OOM and how to configure it, so I wouldn't know. Still, it's a valid stance to say -- as the author of slock: _I don't worry about that, configure your system appropriately yourself._ I find the stance the author of slock did take valid, too, though. It's nice that slock tries to prevent you from falling into that trap.

[lethalman]

@peti except you can't run slock as user and afterwards configure it from root to set the OOM killer. That means slock as to run setuid just for setting OOM. If it doesn't it setuid afterwards, I find that more harmful.

[peti]

I'm not sure whether I follow. Am I understanding you correctly that you feel the required setuid bit is too dangerous to be worth having just so that slock can disable OOM for its process? I.e. having setuid is more dangerous than the OOM killer was in the first place?

[lethalman]

@peti I'm saying that you should be able to run slock as user if you choose not to have the OOM adjustement, but it's not possible.

[peti]

Ah, okay. Now I got it. Yeah, that makes perfect sense. I suppose they don't want to bother with a command-line parser.

[lethalman]

@peti yes, and that it should be enough to warn the user instead of exiting if it's not able to set the OOM adj.

[domenkozar]

So this is won't fix, in NixOS just use security.setuidPrograms.

[vcunat]

We might patch it to convert the fatal error into a warning. It's hard to judge for me if it would be accepted upstream.

[Mathnerd314]

It's not just the OOM killer; slock also needs root to read the password file: 1. Arch works because the Makefile installs slock as setuid: 2.

What's needed for NixOS to have logic like "if this program is installed in systemPackages then make a setuid wrapper for it", so that we don't have to chase down obscure messages in the program's source code...

[vcunat]

I wonder how other screen locker handle the password, as I've certainly run xlockmore without any wrapper or raised privileges.

I don't think we have such automatic triggers based on systemPackages, and I'm not completely certain we should have.

[Mathnerd314]

Other programs call PAM which calls pam_unix which calls unix_chkpwd which is setuid root. And, surprise surprise, if your account is not provided by pam_unix but instead by some other PAM module, you have to make the screen locker setuid.

[ericsagnes]

won't fix, so closing.
Thanks for all the explanations.

[Mathnerd314]

It's not quite "won't fix", it's more like a fuzzy duplicate of #9848 and #6768.

[Mathnerd314]

The real fix to use Wayland (#5071), because that has the screen locking integrated into the compositor.

[srid]

security.setuidPrograms has been deprecated. Use this instead:

security.wrappers.slock.source = "${pkgs.slock.out}/bin/slock";

[ch1bo]

How can this be solved in non-nixos operating systems which just use nixpkgs?

Keeping the setuid chmod in Makefile is not permitted obviously.

[ch1bo]

Okay I just aliased / updated my keybindings it to use sudo slock instead. Please shout at me if this is a bad way of dealing with this or when there is a proper nix-way to this :smile:

[Camsbury]

How to get this working for the xss-lock config?
security.wrappers.slock.source = "${pkgs.slock.out}/bin/slock"; programs.xss-lock = { enable = true; lockerCommand = "${pkgs.slock.out}/bin/slock"; # also tried pkgs.slock };

I have security.wrappers.slock.source = "${pkgs.slock.out}/bin/slock";, but still no luck.

[zeorin]

Assuming you've either set the security wrapper yourself or let the module do it for you:

  programs.xss-lock = {
    enable = true;
    lockerCommand = "/run/wrappers/bin/slock";
  };

This works because the suid version is accessible at that path.
The "${pkgs.slock}/bin/slock" path is the non-suid wrapped binary, and therefore won't work.

Incidentally if anyone knows how to get the suid wrapped path without hard-coding it I'd love to know.

[Mathnerd314]

I guess you could use ${config.security.wrapperDir}/slock. But the comment says it should never be overridden so hard-coding it is fine.

[Camsbury]

Thanks!!!