Hacker News new | comments | show | ask | jobs | submit login
Nix-build freezes system on macOS High Sierra with multi-user install (github.com)
116 points by rnhmjoj 9 months ago | hide | past | web | favorite | 38 comments

`kill(id, sig)` sends signal `sig` to pid `id`. `kill(-id, sig)` sends signal `sig` to process group `id`.

`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.

From a quick reading of https://groups.google.com/forum/m/#!topic/nix-devel/KV9eomId... - it doesn't seem related to sandboxes or anything fancy, it seems like the kill signals go across the basic unix user accounts (uids)

> 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 useful like an atom bomb is useful

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.

`kill(-1, ...)` is a syscall, it's not an application command.

> 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 a headless nixos box installed for over a year now and enjoy using it, but trying to install python,ruby,node / gems / pypackages etc is extremely annoying.

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.

> many of the ruby / python packages I want aren't in the nixos-packages repo yet

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.

Cursed OS point release.

Can we remove the fragment (#issuecomment-335991581) from the submission URL? I see no reason to link to this particular comment.

TL;DR: High Sierra was released with a broken kill system call. It can sometimes cause a kernel panic.

Apparently Apple doesn't think this is a security issue:


Unprivileged users being able to panic the kernel would seem to be security related, but I am just an amateur.

Unless it has a clear exploit it makes some amount of sense to me that this would not be put on a security timeline. But I am not a security expert either.

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.

IT Security is usually considered through the prism of the CIA Triad[1]. Confidentiality, Integrity and Availability.

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...

This is availability of a single system, not a distributed system.

Its the same concept. If a user can't use his computer because of a local DoS its still a security issue.

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.

I get why it's a security issue. My point is that it's not on the same level as a critical vulnerability.

Incorrect. Unprivileged users with local system access and the ability to send kill signals to arbitrary process IDs. Not “unprivileged users” alone.

> with local system access

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.

Well, nobody uses MacOS seriously, so unprivileged DoS and the ensuing data loss is clearly not a security issue.

bad time to be finding bugs in High Sierra

The Nix folks found this bug before 10.12.0 came out; it was actually known well before the more recent bugs of infamy.

Apple just haven't done anything about it until the upcoming 10.13.2 release.

Idk it seems particularly good to me.

Thank goodness they were able to squeeze in those new emojis in the latest release, however!

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)

I get your point but it's rather tiresome to repeat this Emoji jab since clearly the people drawing new emoji will be artists who would hardly be fixing code bugs instead.

But their salaries are paid from the same huge hoard of cash. Infungibility of developer effort is more reasonable excuse for community-driven open-source projects than macOS

I, uh. I think Apple has enough money to hire artists and developers. Their net profits in 2016 were high enough to buy Iceland.

I would imagine that Apple is already considering getting out of the macOS market given the latest round of advertising for their iPad Pro.

As far as I can tell, the only people the iPad is suitable for as a full time computing device are bloggers who write about iPads

If Apple's Mac business was it's own business, it would be in the Fortune 500.[1] I agree that they're pushing iOS hard, but I think as long as revenue is as strong as it has been, this new Post-Jobs Apple won't be getting rid of Macs.

1. https://9to5mac.com/2017/11/02/apple-earnings-fy17-q4/

How do you build apps on iPad Pro?

Playgrounds! :D

No reason they couldn't port XCode to iOS, and given the nature of skunkworks projects in Apple, this may have already occurred. Plus they also have their current installed base of Macs that can still be used even if Apple stops development of new features for macOS while they transition the tools to iOS.

I hope they simply get out of the desktop marked and let us use Linux to build.

I hope not, I like too much having a laptop that actually suspends correctly.

FWIW, the MacBook Pro (late 2016 model with TouchBar) that I'm typing often gives kernel panics on attempting to resume from sleep, but on my new ThinkPad T25 (running NixOS, of course), suspend and resume work OOTB and I've yet to see a problem occur with it.

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.

If it makes you feel any better, my Mac has a sleep/wake failure every week or two and reboots instead of waking up.

Usually it works though!

True, I was blown away by this.

Seems unlikely considering the huge amount of APIs shared between ios and macos that would make porting a working simulator a herculean task. CoreAudio, AVFoundation, Metal, Mach kernel APIs and ports, XPC, CoreGraphics, CoreAnimation, etc etc etc

Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact