Nix-build freezes system on macOS High Sierra with multi-user install
github.com
github.com
`kill(-1, ...)` would signal pgid 1, which would be the process group of init.
From a quick scan of the issue, it looks like maybe nix is using macOS's sandbox feature somehow, maybe that creates a process namespace of sorts and makes `kill(-1, ...)` useful?
EDIT: nvm, there's a special-case for -1:
> If pid equals -1, then sig is sent to every process for which the calling process has permission to send signals, except for process 1 (init)...
I'm surprised this isn't encountered by more people: that seems useful.
It's useful like an atom bomb is useful - a really heavy-handed approach. Usually this is a smell that indicates forking processes are not communicating well.
It's much better to have well-behaved processes. Send SIGTERM to the parent process, allow the parent to perform cleanup of its own children recursively.
It's intended for when you reboot the system, to get every process to quit. And for when you logout, to close everything you have running.
So yes, useful.
When logging out via the OS supplied method this is handled for the user. Why on earth would a user have to call kill -1 on logout?
My comment was from the perspective of an application developer.
> this is handled for the user.
And that's how - they call that syscall.
Maybe you didn't realize. Notice the parenthesis? It's a function call in a programming language. The command line program is just a passthrough to the syscall.
And when rebooting you do need the command line program, so preventing it from passing -1 through doesn't make sense either.
I've had endless problems when trying to just do something like create a virtualenv and get my deps installed to try something out of pypi etc. I'm aware of nix-shell, pypi2nix but many of the ruby / python packages I want aren't in the nixos-packages repo yet. I don't really want to debug / write some crazy nix recipes to just try and spin up a quick pyenv.
Does anyone know if guix is easier to use in this regard? The syntax looks much saner, but I hear it has less support since it isn't as widely used.
They're not difficult to add.
FWIW I've had virtualenvs working pretty well on Nix systems - simply provide the environment with the C-dependencies and `virtualenv` from the `pythonPackages` version you desire. Use that `virtualenv` to create your venv directory and you're pretty much away. Oh and you may have to set the `SOURCE_DATE_EPOCH` environment variable. Pretty much works for me.
Having said that, the whole concept of virtualenvs and for that matter the whole python packaging ecosystem is a series of rather broken ideas.
Apparently Apple doesn't think this is a security issue:
https://groups.google.com/forum/m/#!topic/nix-devel/KV9eomId...
Unprivileged users being able to panic the kernel would seem to be security related, but I am just an amateur.
There was an anecdote in the issue tracker that suggested there was some level of privilege escalation but that did not contain a repro or any supporting evidence.
Therefore any issue which impacts the availability of a service or device is a security issue.
[1] https://en.wikipedia.org/wiki/Information_security#Key_conce...
To make this really simple, imagine if I ran a fork bomb on one server. That makes the server unavailable for users who want to log into it for whatever reason. Therefore it is a security issue.
It doesn't matter if its an end user device, one sever or a distributed system. I as the user cannot do what I want to do. That is what 'availability' means in the CIA triad.
The discussion linked from the github issue sounds like "kill SIGKILL -1" at a shell prompt is enough to trigger the issue. That just requires a shell, not local system access.
> and the ability to send kill signals to arbitrary process IDs
This is precisely the part that is _not_ required but should be.
Finding bugs of this serious nature should always be welcomed, but it should happen in advance of production release. As a result I imagine there will be some new positions opening up in the OS quality testing group, and lower management. Imagine the Steve Jobs rant that would have resulted. (shudder)
Usually it works though!
The GNU+Linux world is always changing, and Linux's hardware support gets better every year. I get the joke-- I've lived through suspend/resume hassles on laptops running Linux before, compiled the custom `tuxonice` kernels, etc. But no manufacturer who sells Linux computers has to ship laptops that have any trouble with suspend/resume, and my luck has been pretty good with a lot of recent, formally non-supported hardware I've tried.
Apple just haven't done anything about it until the upcoming 10.13.2 release.