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)
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.
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.
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
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.
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
`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.
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.
`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.
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.
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.
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.
40 comments
[ 3.1 ms ] story [ 95.6 ms ] threadFinding 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.
1. https://9to5mac.com/2017/11/02/apple-earnings-fy17-q4/
Apple just haven't done anything about it until the upcoming 10.13.2 release.
`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.