71–80 of 82 posts
Earlier quoted context omitted.
Linux is not based on Minix. What Linux does do is that it supports most everything required for POSIX compatibility.
He wrote inspired by, not based on - which is true. Linus Torvalds was inspired by Minix, to write Linux.
Earlier quoted context omitted.
Are you saying you want "sudo" to use a a password entry mechanism which cannot be spoofed or intercepted? Something very similar to this is pretty easy on Linux. If you are willing to pay a little, requiring Yuibikey press for sudo is supported [0]. If you don't want extra hardware, you can use "pam_exec" PAM method to read second factor (like PIN) from "/dev/input/by-id/...". This'll read from specific input device…
A SAK is some action that only the kernel can detect. On Windows user-level programs cannot receive the ctrl-alt-del key sequence, so if you do that and something happens you can be sure you are interacting with the real authentication GUI, not a fake one. I don't think any of your solutions provide that capability.
They do not provide "some action only kernel can detect" -- but I don't think you need this. Linux has strong enough user isolation that userspace programs running as root are as good as kernel is. Let me elaborate on that:
From security standpoint, they are equivalent. If you get kernel access, you can start a userspace root process. If you can get a root process access, you can modify kernel. So being "kernel only" does not really have that many advantages over privileged process.
And Linux kernel provides pretty strong user isolation. In particular, there are two subsystems in Linux which (AFAIK) are not present in windows, and which makes the safe userspace login possible:
- The system does not have a single "screen", instead it has multiple "virtual terminals". All the display/input devices are tied to single virtual terminal, and switching to a different virtual terminal completely deactivates the other one. So, for example, you might have your user's regular session on VT 7. If you somehow switch to the VT 2, then no matter what that user session does, it can no longer affect the display nor read from keyboard until you switch back.
- The kernel provides direct access to the input devices to the root user, via /dev/input/ file. This access happens before regular input layers, and cannot be affected by non-root users at all. So while a user's app can proxy the TTY input, or set up a global keygrab for the X session, or install a strange keyboard layout, this will not affect those /dev/input files at all.
So have a root process that monitors /dev/input/* and switches to a different tty when a designated SAK key is presses. And you have your "real GUI" solved, no kernel needed.
Agree?
Earlier quoted context omitted.
Particularly as the reference UNIX seems to be a Linux with systemd, which isn’t UNIX.
De facto or de jure? Linux isn't technically one, sure, but given that Linux is where the OS hot-shit is now (e.g. eBPF, although I think FreeBSD has the basics - no idea whether it got merged but I saw a student project) is it not fair to say it's where Unix would've been had things been different?
No, it's not fair. Linux is just the OS kernel. UNIX covers interfaces, from APIs to shells and apps distributed by default, which are way out of the scope of Linux. That's the responsibility of Linux distributionsm.
And by the way, there are linux distributions that are certified UNIX
https://unix.stackexchange.com/questions/293396/is-there-a-l...
Moreover, UNIX is standardized. The drive for standardization was derived from the fact that all vendors of UNIX-like OSes were pushing their quirky vendor-specific things. In fact, even within Linux there is no widely established standard regarding basic interfaces, let alone UNIX.
With this in mind, do note that macOS's market share is significantly larger than the aggregate market share of Linux-based UNIX-like distributions.
Earlier quoted context omitted.
Particularly as the reference UNIX seems to be a Linux with systemd, which isn’t UNIX.
> UNIX I don't understand why UNIX is such a big deal in 2020. Linux has won, and at least one BSD has binary compatability with Linux. If anything, we should be taking about Linux compliance. Having no strong package manager story, yet being UNIX compliant, seems like an extremely bizarre priority choice.
If you're interested in learning about why standards are "such a big deal" then you can start by discovering a phenomenon called linux fragmentation".
Earlier quoted context omitted.
There is some value in standards such as UNIX and POSIX compared to whatever the maintainers of a GNU project decided this morning. As for your second point, it just means that package management is irrelevant to UNIX (or POSIX) compliance. It did not prevent different package managers to appear over the years, because all the expected infrastructure was in place.
> It did not prevent different package managers But did these UNIX package managers actually materialize? I guess my point is: is UNIX at all relevant? It had some really good ideas that were worth copying, but the world has moved on to greater ideas.
Obviously yes. I don't understand what is there so hard to understand.
I mean, just go learn about pretty much any field where you need to target a combination of platforms that don't agree on small arbitrary things, and how much wasted effort that consumes.
> Some Differences between macOS and Common Unix Systems ...by which is meant, "Some differences between macOS, a certified Unix™, and systemd/Linux". Which is fine and valuable! But macOS is the most common Unix™, so the title as written is... entertaining.
I worked at a Telco that ran over 100k Linux VMs in one department. Not sure about unix certified os's, but mac os has a much smaller install base than linux.
No, not really. macos's market share is about 4 times the aggregate market share of all Linux-based distributions.
Earlier quoted context omitted.
De facto or de jure? Linux isn't technically one, sure, but given that Linux is where the OS hot-shit is now (e.g. eBPF, although I think FreeBSD has the basics - no idea whether it got merged but I saw a student project) is it not fair to say it's where Unix would've been had things been different?
> Linux isn't technically one, sure, but given that Linux is where the OS hot-shit is now (...) is it not fair to say it's where Unix would've been had things been different? No, it's not fair. Linux is just the OS kernel. UNIX covers interfaces, from APIs to shells and apps distributed by default, which are way out of the scope of Linux. That's the responsibility of Linux distributionsm. And by the way, there are li…
How was I not aware of this? Thanks for the link! And you make a very good point regarding kernel vs OS. I assumed Linux == GNU/Linux in this context (so ignoring Android and others), but it certainly is a gross over simplification.
Earlier quoted context omitted.
The main problem isn't really that it doesn't require sudo. If it installed as a user into your home dir, that would be fine. Changing a shared system-wide path or installing shared system-wide files owned by a user is so fundamentally borked that you should immediately reject anything offered by anyone who suggested to do that. But the masses of users who made it popular didn't know that and there were/are a lot of…
> Changing a shared system-wide path or installing shared system-wide files owned by a user is so fundamentally borked that you should immediately reject anything offered by anyone who suggested to do that. I don't think that's fair to the homebrew developers. They chose a justifiable tradeoff - as you said most mac systems are single user systems and their design offers better protection to a far larger group of use…
All programming, heck all system design of any form, programming, mechanical hardware, legal process, is made of ensuring that situations are handled, including both the obvious ones you thought of and the ones you didn't think of.
All "corner cases" could be described as "contrived", yet they happen a million times an hour.
"Contrived" is a contrived rationale to ignore something you should not ignore for mere convenience.
"contrived" is just a silly and empty accusation, and no argument.
If you are in a conversation where the subject deals in probabilities or percentages, then you can talk about liklihood. Having say 1% of customers fail to navigate a subway map is better than having 8% fail. And some contrived example problem like the map needs to be only in shades of green because what if you're colorblind... the contrived nature of the problem matters because the problem deals in percentages where 99% is better than 92%.
But in system design (such as application programming or os design, especially the lowest most basic security aspects, things are only possible or not-possible. There is no "likely" and no "contrived". If you can "contrive" an example that invalidates a design, then you have invalidated the design, period.
If you cannot contrive an example, then you still have not proven the design, merely you have failed to IN-validate it, yet.
The /Applications directory is not equivalent to the /usr/local tree, or any other part of the system.
The /Applications dir itself is owned by root, and a user may not change it to be owned by theirself, and a user may only write within it because they are a member of the "admin" group. Until recently, the homebrew installer actually changed the ownership of /usr/local itself (or created it, I don't remember if it maybe didn't exist by default and was created by brew sometimes) rather than just some of the stuff under it. They only changed when forced to, when Apple started more actively protecting system components from modification a couple years ago. If it's ok for shared system components to be owned by joe random user, then why did Apple start protecting /usr/local? For that matter why can't joe random user replace /bin/cp with his own copy, or the kernel?
/usr/local/bin/mycp is (or rather should be, and is on sane sysyems) just as much a protected part of the system as /bin/cp. It's only different in that it's locally added to this machine and didn't come on the install cd, and may have different behavior than other parts of the system expect etc. But it's not "steve's" either. A "mycp" owned by "steve" should only exist in /home/steve (or /Users/steve on mac).
If brew installed everything in /Applications/Brew.app that would be ok too, because then it would be just doing what other apps do, and because /Applications is a special case which has extra handling by other means than merely the traditional unix file ownerships.
That would still be mildly broken because it would mean that all users could use the brew binaries and other assets, but only the installing user could modify them. That is fine for most apps which do not modify their internal contents, but brew is essentially a whole system itself, and it's contents are modified during normal use. A theoretical Brew.app is not like Calculator.app
So, the only sane way to do it is to install as the user somewhere within the users own domain (their home dir) or install in a system-wide shared place and require sudo for any "brew update" or "make install".
If it were all owned by a special user and/or group "brew" (not whatever random user happened to do the install), that would be sane too, but not necessary.
Not quite on this topic, but I have always felt Linux security seems lagging behind macOS. Linux seems lacking on sufficient sandboxing. I am also increasingly uncomfortable with so many repositories, FOOS on GitHub and users sudoing left and right. I am not sure if I am correct though.
Debian (and derivatives) and SUSE use AppArmor but IIRC with more permissive, looser policies. At least Debian does IIRC. SUSE might put in the extra effort to harden them a bit, I'm unfamiliar with their ecosystem.