> DSLR's approach to security is different . It is possible to run as root without causing a global disaster.
Is there any more information available on how this is achieved?
Basically you design the system so that root has no special powers. Imagine if all of your storage was write-once, like a CD-R. What damage could root do? Almost none. Maybe there is a union file system for /usr and /home. Disregard all changes to /usr, when you reboot a fresh /usr is extracted from disk. Stuff like /home is incrementally saved. You can re-wind to any point in history. That is how Puppy (in CD-R mode) works.
About the only real threat that root poses is accidentally dd-ing over the OS boot partition. With some kernel patching you could simply hide the /dev node after the boot is done with it. Though that makes updating harder. Any threat can be neutralized, but the whole OS gets slightly more byzantine as a downside.
The root/user distinction places all your faith in octal permission bits. In some ways a properly designed run-as-root system is less risky, because the safeties are baked into the OS at a much deeper level. It is the difference between a dangerous machine having physical safety interlocks and paper-thin "for your safety" policies.
At some point we have to make the call on diminishing returns. It will always be possible for root to bork a system (without a rewrite of many, many utilities that rely on root permissiveness), it's just a matter of how hard we can make it to do that accidentally. To be clear, I think this work is very useful and appreciated though. As someone that spends almost all of every working day in terminals on remote systems, often as root, I applaud any effort to reduce catastrophic mistakes. Every time I have to rm -rf as root there's that little after-I-hit-enter-panic, where I have to assure myself I double checked and didn't accidentally just delete /bin. The root is protected from the errant rm mistake, but there's oh so many more ways to reduce a perfectly fine system to an unbooting heap of hardware.
> The root/user distinction places all your faith in octal permission bits. In some ways a properly designed run-as-root system is less risky, because the safeties are baked into the OS at a much deeper level. It is the difference between a dangerous machine having physical safety interlocks and paper-thin "for your safety" policies.
Give me both. Please.
> Is there any more information available on how this is achieved? +1 to this remark, currently unanswered. Is the "NEVER RUN AS ROOT!" mantra from modern Linux practices, or has it been that way since the mid-90s? After nearly four years of using Fedoras, I'm getting better about remembering what operations require root privileges, but I'll still grumble every time I have to enter the root password to do something as trivial as mounting a flash drive on someone else's computer. (I can't remember, offhand, where that setting is/what it's called that lets normal users mount drives)
I think that goes back all the way to Unix and its multiuser environment, where one admin's mistakes could affect everyone on the system - so people were naturally scared of root.
On the other hand, on the earliest personal computer OSs, which were basically single-user (many don't even have the concept of a "user account"), that only user has full control like root but that wasn't really perceived with as much apprehension since the only thing a mistake affects is the sole user.
With DSLR and all the other tiny Linux distros, I sense that the intention is these are to be used by a single user.
That is why I avoid running as root.
The other late evening, I typed "sudo pip uninstall pip" instead of "sudo pip uninstall pil" Not that bad, but i was on an outdated distro (13.04) and I couldn't apt-get pip back. :< It was time to move to 13.10 anyway.
I don't care if I "rm -Rf /bin" because I can reinstall all of it in less than an hour. It's an inconvenience, but hardly the end of the world.
On the other hand, "rm $HOME/*" would be a huge pain in the ass, potentially losing personal data that I can't just "apt-get install _____" back.
It does make sense for shared computers, but not many people running OSX and desktop Linux are running on shared computers.
Obligatory mention, the QNX demo disk (1.44M floppy image with full gui):
http://toastytech.com/guis/qnxdemo.html
While the floppy is justifiably dead, it is a little strange to see basic installs taking up so much space these days. Thankfully the core-os type projects (os for densly populated vm servers) are helping a bit -- even if deduplication/running root from /nfs etc -- is probably a more expedient (and permanent) way to reduce footprint per vm (1 Gig divided by 1024 vms is just 1Mb per vm after all...).
Not a *nix-like but has a ton of functionality in the space of a single floppy.
</sarcasm>
http://ftp.gwdg.de/linux/mulinux/ http://en.wikipedia.org/wiki/MuLinux
It was one of my first distro and it was awesome. A base system than ran in one floppy and then you could optionally add and combine more floppys depending of what you wanted (X system, IDE, games, latex, etc...) It was kind of the ancestor to Live CD