http://www.infoworld.com/article/2988096/mac-os-x/sorry-unix-fans-os-x-el-capitan-kills-root.html
If you haven't heard, Apple has locked out root from various file system paths and core functions in Mac OS X 10.11 El Capitan. The new sheriff here is System Integrity Protection (SIP), which reduces root privileges in an attempt to increase security.
The gist is that no user -- not even root -- can write to /usr, /bin, /System, and /sbin or debug protected processes. Apple has also removed the ability to use unsigned kernel extensions through boot-time flags. It's important to note that SIP can be disabled, through the recovery partition, but this will typically be done only for development and testing purposes.
From a Unix purity perspective, this ain't great. There's a reason that root exists, and there's a reason why root has omnipotent access to the system. It's part of the Unix philosophy. That said, Mac OS X 10.11 may be Unix, but it's not a server. It may not even be a workstation in the traditional sense anymore. It's now a desktop OS exclusively, and treatments like this should be expected.
(Score: 5, Informative) by Anonymous Coward on Thursday October 08 2015, @06:58AM
The important thing is not whether root has complete access to the system. Root is just a user with a historical name. The important thing is that the owner has complete access to the system.
If you don't have complete access to the system, you are not the owner.
For the same reason, gaining full control of someone elses system is called "owning" that system. Though often spelled "pwning".
(Score: 1) by massa on Thursday October 08 2015, @01:31PM
YES. THIS.
OTOH, if the phisically present owner has to jump thru some hoops before hosing the system, it's a reasonable thing. The problem here is keeping one without losing the other.
(Score: 2) by DeathMonkey on Thursday October 08 2015, @06:01PM
For the same reason, gaining full control of someone elses system is called "owning" that system. Though often spelled "pwning".
It's also know as "rooting" the system, to bring us full circle.
(Score: 2) by darkfeline on Thursday October 08 2015, @11:47PM
>The important thing is that the owner has complete access to the system.
In order for that to be possible, there needs to be one user or one set of users who together possess full permissions on the system. We call such a user "root" as a matter of convention. You can disable the root user and give, say, the bob user full sudo permissions, but ultimately someone has to hold root permissions.
Join the SDF Public Access UNIX System today!
(Score: 3, Interesting) by Gravis on Thursday October 08 2015, @06:59AM
OSX has never been about user control, so this only helps harden the system from possible outside attacks. if this update rubs you the wrong way then it seems your EULA leash just got yanked on by Apple.
(Score: 0) by Anonymous Coward on Thursday October 08 2015, @07:40AM
Reminds me of the extra control windows Vista grabbed. "For security" of course.
The "fixed" Windows 7 never had that control returned to the user.
(Score: 0) by Anonymous Coward on Thursday October 08 2015, @11:45AM
To what are you referring?
(Score: 1, Interesting) by Anonymous Coward on Thursday October 08 2015, @03:46PM
The Administrative User no longer has access to the machine: only the System user [technet.com] has that power.
(Score: -1, Flamebait) by Anonymous Coward on Thursday October 08 2015, @04:39PM
Poor baby. Shall I call the waaaahmbulance?
(Score: 0) by Anonymous Coward on Thursday October 08 2015, @08:05PM
Why would I need a wambulance if I don't even use such a system?
(Score: 3, Insightful) by Anonymous Coward on Thursday October 08 2015, @07:14AM
The gist is that no user -- not even root -- can write to /usr, /bin, /System, and /sbin or debug protected processes.
Well, not really root then, is it? Doesn't matter what you call it, root, superuser, MCP (yoh! TRON reference!), it is the owner of the system. If it cannot right to certain directories, it is not the owner of the system, some one, or something else is. Skynet, anyone? Crap, now all we have to to is crack the mother-lode hive-mind of the Central Operating Authority that is Apple, and, oh, I feel weak. I love Steve. Steve Jobs. I want to download iTunes. Yes, I will pay. Why are you looking at me like that?
(Score: 0) by Anonymous Coward on Thursday October 08 2015, @08:24AM
As long as you have control to which directories are searched for executables, I don't see a big issue. After all, /bin is just a name, right? so make a directory /mybin, put it in the search path before /bin (or even replace /bin by /mybin in the search path and copy all executables over), and call it a day.
I don't know how much the /System name is ingrained in OS X, so I can't tell how much locking that directory matters.
Anyway, the summary says you can disable that protection; as long as there's an officially supported way to do that without needing to access some external service for that purpose, I don't see any issue. The average user (who doesn't need to write into /bin anyway) is protected, but if you need to change it, you can do so.
(Score: 3, Interesting) by theluggage on Thursday October 08 2015, @10:48AM
it is not the owner of the system, some one, or something else is. Skynet, anyone?
The owner of the system is the lump of meat with physical access to the system who can boot it up into single user, recovery or target disc mode and change what the heck they like (including installing Linux if they want a fully open OS).
So far, Apple have reserved any attempt to stop that to their iDevices (which have been locked down from day one).
(Score: 0) by Anonymous Coward on Thursday October 08 2015, @11:48AM
God, these Skynet references are stupid, and tiresome.
Did I say "stupid"? And over-used.
Quit it.
(Score: 2) by Tork on Thursday October 08 2015, @05:17PM
It's weird to me that nobody remembers that epilogue at the end of T2.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by tangomargarine on Thursday October 08 2015, @07:11PM
Doesn't it transition from self-defense (killing the people who can turn you off) to genocide (wiping out the entire human race...because the last one left alive might figure out a way to turn you off) at some point?
Cf. theory of democracies not fighting each other. Can you have a war where both sides can logically claim self-defense?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by Tork on Thursday October 08 2015, @07:35PM
Doesn't it transition from self-defense (killing the people who can turn you off) to genocide (wiping out the entire human race...because the last one left alive might figure out a way to turn you off) at some point?
Whether or not Skynet would stop at extinction of the human race has not been established. Given what we know about that character of that particular ... um.. being, we have some reason to believe that it would come down to a question of resource usage. Is it worth, say, flying to the other side of the planet to nuke a village of people who have no technology anyway? We don't know. What we haven't seen is Skynet behaving irrationally. Terminators are quick to kill, but they don't savor it. The most notable time we see a Terminator torture anyone is a means to an end, trying to get Sarah to call for John. That is not the behavior of one out for revenge.
Can you have a war where both sides can logically claim self-defense?
Yes. Although I wonder if you meant to ask: "Can you commit genocide with a reasonable claim of self-defense?" In Skynet's case, possibly. The difference is that it is one very large entity, its death is basically genocide. If the entire species heads for its destruction because it poses a threat to that entire species, then what is it supposed to do? Say "I give up" and die?
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by tangomargarine on Thursday October 08 2015, @08:12PM
Whether or not Skynet would stop at extinction of the human race has not been established.
Um...what? I think you mean "stop before the extinction of the human race." Or perhaps SkyNet would go on to kill the smarter species of monkeys?
What we haven't seen is Skynet behaving irrationally. Terminators are quick to kill, but they don't savor it. The most notable time we see a Terminator torture anyone is a means to an end, trying to get Sarah to call for John. That is not the behavior of one out for revenge.
Yeah okay. I never said anything about irrationality or revenge.
The difference is that it is one very large entity,
It is? I don't remember that. I mean, every Terminator has its own chip so I can only assume they're running locally. They're not the Borg. SkyNet is just the "Joint Chiefs" back home giving them marching orders, if you will. In which case, SkyNet itself is unique, yes, but all the individual Terminators really aren't.
Sounds like what really needs to happen is the humans and SkyNet negotiate a DMZ or something.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by Tork on Thursday October 08 2015, @09:17PM
Um...what? I think you mean "stop before the extinction of the human race."
Sort of. A longer version of that sentence would have been: "Whether or not Skynet would stop at extinction of the human race or merely at their neutralization has not been established." My bad.
Yeah okay. I never said anything about irrationality or revenge.
You're operating from the assumption that Skynet's goal is genocide. I pointed out that the (first two) movies did not establish that, and from what we can intuit from what we've seen there isn't a strong reason, even vengeance, to assume they would.
It is? I don't remember that. I mean, every Terminator has its own chip so I can only assume they're running locally.
Terminators are not independent beings and not to be confused with Skynet. They are, at best, soldiers. In fact there's a deleted scene from T2 that establishes that their brains are set to 'read-only', incapable of independent thought.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 5, Informative) by fleg on Thursday October 08 2015, @07:25AM
thanks for the submission darkfeline, i had missed this completely.
bit more info here...
http://arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-the-ars-technica-review/8/ [arstechnica.com]
must admit i dont think i care, the one time (over the past 3-4 years of using osx) i put something in /bin it could just as well have gone it /usr/local/bin i just couldnt be bothered typeing the extra characters.
(Score: 3, Insightful) by ticho on Thursday October 08 2015, @07:26AM
Doesn't grsecurity's RBAC do exactly the same? Even if you are root, if you are not switched to proper role, you can't to anything.
The difference here may be that RBAC provides a way to get elevated access, while Apple's system might not (dunno, haven't bothered to read TFA yet).
(Score: 4, Insightful) by TheRaven on Thursday October 08 2015, @09:59AM
It's a little bit like this, but also inherits a lot from BSD securelevels. FreeBSD sets the system-immutable bit on a lot of system files by default. Even root can't modify them. At the normal securelevel, however, root can remove the system-immutable bit and then modify them. If you raise the securelevel, system-immutable becomes monotonic - you can set it, but you can't remove it. You can set the securelevel that will be set on boot (you can always raise it later, but you can't lower it without a reboot).
The reason that most people don't do this on *BSD (I did for a while, but it's annoying) is that upgrades become a pain. You have to boot to single-user mode (without raising the securelevel), then run the update, then reboot again. On OS X, the system upgrade process does this for you. You also can't load kernel modules at higher levels (on OS X, you can only load signed kernel modules).
sudo mod me up
(Score: 1) by mobydisk on Thursday October 08 2015, @06:29PM
This sounds a lot like EWF and FBWF on Windows Embedded. You can set either an entire partition, or specific folders, to be read-only. It also supports an overlay so you can write to them, but the changes are actually stored on a differential partition or in memory. When you reboot, the changes are reverted. Much like the BSD feature, you can disable it only upon reboot. It similarly makes upgrades a pain because the process is basically the same as what you said in BSD: reboot with EWF/FBWF disabled, do your updates, then reboot with EWF/FBWF enabled.
(Score: 2) by TheRaven on Friday October 09 2015, @08:43AM
sudo mod me up
(Score: 3, Insightful) by WillR on Thursday October 08 2015, @02:14PM
Constraining the omnipotent powers of root isn't anything new, people are just getting worked up because Apple.
(Score: 0) by Anonymous Coward on Thursday October 08 2015, @08:36AM
SYSTEM is root.
Administrator can't do much. But still enough to compromise a system's integrity.
And on selinux, root can be stripped back to have no privileges.
(Score: 5, Insightful) by theluggage on Thursday October 08 2015, @09:27AM
The gist is that no user -- not even root -- can write to /usr, /bin, /System, and /sbin
[SNIP]
From a Unix purity perspective, this ain't great.
...but you can still write to /usr/local or /opt which, if you give a fig about Unix purity, is where you should be doing any customisation, anyway.
or debug protected processes.
Which pretty much qualifies as "only for development and testing purposes" and is exactly why you'd disable SIP (which is done with an official Apple utility BTW, not some 'jailbreak' hack).
That said, Mac OS X 10.11 may be Unix, but it's not a server.
...more to the point its a personal computer OS, where the vast majority of users need 'sudo' access so that they can change settings and install software, but can't be trusted not to dutifully enter their password whenever some bit of malware asks for it. Plus, we're living in a world where virtually every OS developer has shown that, while privilege escalation bugs shouldn't happen, they do and both belt and braces are required. The 'root' model isn't viable on BSD or Linux any more, either (hence developments like SELINUX).
It's now a desktop OS exclusively
Nonsense. All the command-line stuff is still present and correct and /usr/local is still yours to play with - plus you can disable it. If you really want to dick with /bin, why would you do that on a running system? Its the 21st century and we have virtual machines for that.
Yes - there have been a few casualties due to 'abandonware' that is probably never going to get updated - but that is more about the insanity of releasing a new OS every year rather than any specific feature. Apple has enjoyed a certain advantage over Windows is that their customer base is less obsessed with backwards compatibility and they don't have to keep legacy stuff forever - but compatibility-breaking OS updates every year is a bit much. OTOH, the 'stability' of Windows in the XP era was maybe more by accident than design, and it looks like the new Windows model is that you're going to get future major updates pushed on you whether you like it or not.
Maybe, at some stage, Apple will decide to lock the doors for real - so far, though, they seem happy to reserve that treatment for iOS.
(Score: 0, Funny) by Anonymous Coward on Thursday October 08 2015, @11:53AM
Man, I love it when someone who actually knows and understands what he's talking about bitch-slaps the idiots who think they do. "I run linux, so therefore I understand the Unix philosophy and free software."
You go girl!
(Score: 5, Insightful) by boltronics on Thursday October 08 2015, @12:32PM
Don't be fooled; this is just the first step. Eventually OS X will be locked down just as much as iOS, and applications will only be installable through an Apple store. You soon won't be able to bypass SIP, and root won't be able to bypass the Apple store DRM restrictions.
That's the endgame here, and it's plain as day. Apple's not doing this to improve your security - they are doing it to improve *their* business security.
It's GNU/Linux dammit!
(Score: 5, Insightful) by theluggage on Thursday October 08 2015, @01:39PM
Don't be fooled; this is just the first step. Eventually OS X will be locked down just as much as iOS, and applications will only be installable through an Apple store.
Well, that's what people said in 2012 when they introduced "gatekeeper" that let you choose the 'apple store only' option. It still lets you choose.
You soon won't be able to bypass SIP
In a year's time, when everybody's got the memo about /usr/local and /opt, that won't matter - although they'll have to have a solution for developers working on drivers etc.
Could Apple decide to lock down OS X like iOS? Of course, but they'd have to sort out something for developers... and we won't notice because of all this crying wolf every time they add a bone fide security feature. More likely, they'll just decide there no money in Macs any more, release an iOS development kit for Windows or Linux and drop OS X.
At the moment, though, it seems to be MS that are pushing the evil envelope with compulsory updates and phoning home.
(Score: 4, Insightful) by boltronics on Thursday October 08 2015, @10:45PM
Well, that's what people said in 2012 when they introduced "gatekeeper" that let you choose the 'apple store only' option. It still lets you choose.
No, they won't completely lock down access so quickly. First, they have to get to the point where it's actually inconvenient to not be locked down. Then when most people won't see any difference, that's when they'll force it, in the name of consistency and security of course.
Could Apple decide to lock down OS X like iOS? Of course, but they'd have to sort out something for developers...
Web developers would mostly use interpreters such as Python, Ruby, etc, which would be available from the store at no cost (assuming the license allows for it) - or you would run a GNU/Linux VM as many web devs already do. Developers of Apple store apps would require a developer key to develop and execute their own applications on their machine, which people would have to sign up for some sort of Apple-equivalent of MSDN - where you need to prove you are a developer, understand the license terms and pay a reoccurring fee. I don't see any technical issue preventing this.
At the moment, though, it seems to be MS that are pushing the evil envelope with compulsory updates and phoning home.
You know it's bad when you need to compare your OS to Windows, but it's unsurprising since they are both proprietary. If you truly care about real security and control, free software is the only option.
It's GNU/Linux dammit!
(Score: 0) by Anonymous Coward on Thursday October 08 2015, @01:55PM
That move doesn't necessarily make sense if PCs are not the where the revenue will be, yet are strategically important.
(Score: 2) by Pino P on Thursday October 08 2015, @04:51PM
qualifies as "only for development and testing purposes" and is exactly why you'd disable SIP (which is done with an official Apple utility BTW, not some 'jailbreak' hack).
Does Apple charge a recurring fee to use this utility? Until Xcode 7, Apple charged a recurring fee just to run executables that you compiled on an iOS device that you own.
(Score: 2) by theluggage on Friday October 09 2015, @04:53PM
Does Apple charge a recurring fee to use this utility? Until Xcode 7, Apple charged a recurring fee just to run executables that you compiled on an iOS device that you own.
No - not on OS X.
iOS has always been a closed system - like it or lump it - although the developer scheme fees have always been within the reach of hobbyists or cottage industry, a fee is a fee. OS X has always let you compile and run anything you like, and come with free developer tools (you need an Apple account, that's all). All the walled gardens (apart from running OS X on non-Apple hardware) have gates. The possible exception to this is the lockdown on kernel extension signing.
Yes, Apple could decide to slam the doors one day. That's the day a lot of Mac users switch to Linux.
(Score: 3, Interesting) by darkfeline on Thursday October 08 2015, @11:54PM
No, UNIX principle says that you should be allowed to shoot yourself in the foot.
Yes, you're supposed to put things in /usr/local/bin instead of /bin. You should still be allowed to put things in /bin though. This has both practical motivations (if some freak accident breaks something in /bin, you can fix it using root instead of relying on some specially-made OSX tool or booting a live CD) and philosophical motivations (the OS should not be able to forbid me from doing the things I want to do, even if said thing is `for i in /dev/*; do dd if=/dev/zero of=$i bs=4M; done`)
Join the SDF Public Access UNIX System today!
(Score: 2, Interesting) by Anonymous Coward on Thursday October 08 2015, @09:37AM
From a Unix purity perspective, this ain't great.
Why would that be? Plan 9 doesn't have a traditional superuser or root, and it's more Unix than any Unix will ever be.
(Score: 2) by LoRdTAW on Thursday October 08 2015, @03:19PM
Plan 9 is Unix 2.0. It has a brilliant design and aims for simplicity. Linux and OSX all want to be like Windows. Don't be Windows.
(Score: 2) by Eunuchswear on Thursday October 08 2015, @09:49AM
No it isn't, it's simply laziness.
Lots of Unix systems have had limits on what root could do, for example on my systems at work root can't write (or often read) user home directories.
Watch this Heartland Institute video [youtube.com]
(Score: 2) by DNied on Thursday October 08 2015, @11:20AM
So who can disable those limits?
(Score: 0) by Anonymous Coward on Thursday October 08 2015, @12:13PM
Maybe the sysadmin of the file server that contains the home directories?
(Score: -1, Offtopic) by Anonymous Coward on Thursday October 08 2015, @10:28AM
From a Unix purity perspective, this ain't great
HA! How ya like your system-D now?
(Score: 0, Offtopic) by Anonymous Coward on Thursday October 08 2015, @10:48AM
Is there any way to update without a credit card? Wife's computer is on Yosemite, got the upgrade notification, cannot upgrade because iTunes requires credit card info now.
This was originally running Lion, so I've gotten a few years of free upgrades, and I'm pretty sure that thw upgrade to Yosemite bugged me about a ccard as well, but that wasn't a showstopper at the time.
(Score: 1, Funny) by Anonymous Coward on Thursday October 08 2015, @01:07PM
I guess it's on topic since I can't upgrade and still have a functioning root?
(Score: 2) by darnkitten on Thursday October 08 2015, @11:16PM
I've run into this several times recently, and have used a visa-branded gift card in lieu of a credit card with no problem.
(Score: 2) by NotSanguine on Thursday October 08 2015, @12:36PM
I read TFS and the bits about this from the Ars Technica piece and my main reaction was "so what?"
Apple restricted modifying system files/folders, and removing those restrictions requires *physical access* (boot into recovery mode and change settings). Given the (lack of) tech savvy of most Mac users, this is probably a good thing.
Limitations on 'root' access has been implemented, in various forms, for *decades* by various flavors of Unix, and SELinux provides similar controls.
If you need this access (and most Apple users certainly don't), you can get it pretty easily. I imagine that most OS X users won't even notice.
Full disclosure: I'm not an Apple fanboi -- in fact, I don't own *any* Apple hardware, and I don't miss it a bit.
Geez Louise! Get a grip folks. Can't we freak out about something *really* important, like the fact that scientists in Antarctica have the gall to get lit up now and again? This could destroy civilization as we know it!
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 1, Touché) by Anonymous Coward on Thursday October 08 2015, @04:42PM
As long as it is replaced by a better civilisation, I can't see any downside to that.
(Score: 2) by Alfred on Thursday October 08 2015, @01:50PM
" rel="url2html-20445">https://en.wikipedia.org/wiki/Single_UNIX_Specification
Every version since (except Lion) has been registered as meeting the spec.
They don't really advertise that anymore. I suspect that anyone who remotely understands the significance is not suckered by all the Apple gloss. They might say OS X is built on rock solid Unix or some other marketing speak in passing. But as others have said the typical mac user doesn't know or care what anything related to Unix even means. As long as being built on Unix does not make it less pretty, then they are fine with it.
(Score: 2, Interesting) by McD on Thursday October 08 2015, @02:05PM
As the Ars Technica article [arstechnica.com] points out:
OSXFuse is a great open source utility that's crippled by this move because their code isn't signed by Apple.
I like code signing. But I don't like it if only the vendor, not the USER, can specify the set of signing keys to be trusted. (Looking at you too, Mozilla...)
I'm glad these new SIP protections can be turned off - but the way is paved for Apple to slam that door shut in the future with relative ease. (For example, if it should prove useful to them to do so in some hypothetical negotiation with Hollywood.)
(Score: 2) by jmorris on Thursday October 08 2015, @03:31PM
Exactly right. The whole thing with 'Trusted' computing comes down to Who is doing the Trusting. If it ain't me then I, pretty much by definition, do not trust it.
That means if there are keys I either get them or a way to add my own and remove any I decide I no longer trust.
And most Penguin Peeps have no room to gloat on this topic, Pottering has already laid out his plans for the Glorious Future and they are pretty much the same. No more root user, all 'Freedom' ends when the distribution install image is spun. So Open Source is for the hardware maker, server farmer and other big user but everyone else wears somebody's chains. Somehow this will lead to The Year of the Linux Desktop or mumble mumble.. oh shut up it is for your own good!
(Score: 1) by eravnrekaree on Thursday October 08 2015, @03:32PM
Root has not been one of the bright spots of Unix security-wise. The older UNIX file security model is weak in comparison to the newer systems that have become available. Many servers used to run root because of only root being allowed to open a low numbered port, which is an insanely stupid quark of the system. With the availability of a filesystem overlay, the need for installers to have access to root is much weaker, with an overlay everything it does can be contained within the overlay and rolled back if needed. The idea an installer would need access to the entire filesystem to install a single program is backwards. As the article said apple does not lock out root in a way that cannot be disabled.
(Score: 2) by WillR on Thursday October 08 2015, @03:45PM
From a Unix purity perspective, this ain't great.
From a Unix purity perspective, you shouldn't have been installing things in /bin, /sbin or /usr in the fist place. Local installations should have always been in /usr/local or /opt/$PACKAGENAME, even when the SIP nanny wasn't watching.
(Score: 3, Insightful) by fnj on Thursday October 08 2015, @04:36PM
You completely miss the point. It's not about what you "should" be doing. It's about the definition of root. From The Linux Information Project [linfo.org]:
"root is the user name or account that by default has access to all commands and files on a Linux or other Unix-like operating system. It is also referred to as the root account, root user and the superuser."
Find an authentic definition anywhere else, and it is going to say essentially the same thing.
The essence of UID 0 (root) has always been that it completely bypasses permission bits. Historically you could always create a file, chmod it to 000, yet UID 0 could still see it in a directory listing, read from it, write to it, and do anything else to it including chmod it to some other mask. In this, UID was special. It was the one and only UID that had this power. No other UID can be given the power. You can make 10 users, all of them UID 0, each with a different name, and they will all have this power (there are downsides to doing this, but you can verify that you can do it in a real UNIX type OS that hasn't been fucked up).
There is a damn good reason why UID 0 is special. You can always go back to square one, and acting as UID 0 you can fix any kind of fucked-up permissions and the like.
Now, you can layer additional protections on top of the permission bits, such as SELinux in linux and Capsicum in FreeBSD, and UID 0 generally does not have a magic wand to defeat them like it has for permission bits. But that should be the decision of the sysadmin. A "clean" system should not have that stuff. You should always as sysadmin have the option to run a "clean" system.
(Score: 2) by WillR on Thursday October 08 2015, @08:17PM
(Score: 2) by fnj on Sunday October 11 2015, @03:50AM
Ever used Heurikon Unix System 5? SunOS 3.0 which was BSD 4.2? NetBSD? OpenBSD? FreeBSD? I did, all of them, and I can assure you UID 0 is not restricted out of the box on any of them. It has nothing whatever to do with GNU or Linux. It was the norm before they were even dreamed of.
(Score: 2) by digitalaudiorock on Thursday October 08 2015, @06:48PM
The scary part about all this is that clearly "something" can write there...it's just not "you". I'm not a fan of proprietary operating systems...this is why.
(Score: 2) by FatPhil on Thursday October 08 2015, @08:18PM
# man capabilities
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by darkfeline on Friday October 09 2015, @12:06AM
I have a question for those who think this is strictly an improvement.
What do you do if permissions get fucked up? Let's say you run a perfectly architectured permissions system, such that no user has root level permissions. Now through some OS bug or cosmic ray, permissions get fucked up and the system is unusable. If you had a root user (an omnipotent user), you could fix it. If not, you would have to shut down the system, boot from some kind of Live CD, then fix it there.
Fundamentally, there's no difference other than making it more of a hassle. Yes, the Live CD approach is limited to physical access, but you can also limit root to a local console as well. In the end, it's just dumbing down the system to thwart fools.
Join the SDF Public Access UNIX System today!