It's not like python isn't available on every major linux distro. It's a little harder to ensure it's on windows, but when Steam is installing every point release of the Visual C++ runtime that has ever existed on my system, why not bundle python in there too?
Because admins gotta admin. Also, adding python to a software suite just to work on the file system... gross.
I have often made this argument in the context of sandboxing communications software like browsers and e-mail clients, where it is relatively unusual to need access to local files except for their own data. In that context, restricting access to other parts of the filesystem unless explicitly approved would be a useful defence against security vulnerabilities being exploited by data from remote sources. It’s hard to encrypt someone’s data and hold it for ransom or to upload sensitive documents if your malware-infected process gets killed the moment it starts poking around where it has no business being.
More generally, I see no reason that we shouldn’t limit applications’ access to any system by default, following the basic security principle of least privilege. We have useful access control lists based on concepts of ownership by users and groups and reserving different parts of the filesystem for different people. Why can’t we also have something analogous where different files or other system resources are only accessible to applications that have been approved for that access?
I think OS X (and mobile app development in general) shows both that this is great in theory and a net improvement over not having it, but that there are some common pitfalls to address.
First, there are a handful of apps where this model doesn't work so well -- e.g. text editors, FTP clients, etc. So you're inconveniencing quite a few legit apps which need broader access.
Second, as a corollary of the first, that means you're going to have a lot of apps that legitimately need to ask users to approve broader access. And as the number of apps asking for approval goes up, the more likely users are to simply ignore the warning and approve all. This is especially problematic since we can assume the average user is a good judge of which apps need which access.
Edit: One way of reducing user acceptance fatigue might to introduce greater granularity into the requested permissions and then tier the permissions requested -- e.g. commonly asked vs. uncommon. E.g. an app may legitimately need permission to write to any file in your home directory, but it's highly unlikely they'll need permission to write to more than X number of files per second. Or at least they shouldn't be able to do so without the OS throwing up lots of warnings outside of the app.
For files and folders the user cares and knows about (documents, projects, etc), this shouldn't be a problem. For files the user doesn't care about (caches, configuration), you can just leave them in your sandboxed container.
[1] https://developer.apple.com/library/mac/documentation/Securi...
As far as Apple's implementation goes, sandboxes are for kids, not adults that need to get work done.
The truth is that they are too hard for even your average Sysadmin to configure & manage, let alone your average desktop user.
setenforce=1 (yeah, right).
I’d like to see the industry moving in that general direction, though. Even a much simpler model could bring real benefits relative to the status quo, where in application terms our current security model is analogous to everything being root.
However, applying program-level access control is very un-UNIX. How do you compose multiple programs with different security regimes? This bug happened because the "steam" program called the "rm" program via the "shell" program. Inheriting capabilities mostly solves this, but we're familiar with how hard selinux is to use as a result and it still doesn't save the user from command line typos.
I think it's time to make a stronger case for time-reversible filesystems. Accidental deletion matters less if you can just get in your time machine.
The real issue lies in the fact that the file system resides in a global namespace, when it shouldn't. Much like each process has its own environment variables, so should it have its own namespace. Linux does support so-called "mount namespaces" now, but once again they're not inherent parts of the system, but have to be tacked on through explicit unshares, and thus lose the cohesiveness of platforms such as Plan 9. [1]
Something like Windows Store apps, but which ideally wouldn't require the use of a specific store? (Only Entreprise apps can bypass the store from what I know)
Sure, this Steam thing sucks but your disk could die any moment; be prepared. RAID is not backup
# figure out the absolute path to the script being run a bit
# non-obvious, the ${0%/*} pulls the path out of $0, cd's into the
# specified directory, then uses $PWD to figure out where that
# directory lives - and all this in a subshell, so we don't affect
# $PWD
STEAMROOT="$(cd "${0%/*}" && echo $PWD)"
[...]
# Scary!
rm -rf "$STEAMROOT/"*
The product/update is hyped and the release date is set in stone. Tensions are high and your boss has already let you know that you're on thin ice and not delivering on the project goals.
A last-minute showstopper bug comes in, caused by file leaks. Everyone is scrambling, and the file belongs to you so its on you to fix it alone. There is no time for code review, and delaying isn't an option (so says management). "I'm afraid if we keep seeing these delays in your components, we might have to consider rehiring your position".
The rm rf works -- it's a little bit scary, but it works. You write a test case, and everything passes. Still, you add the "scary" line for good measure. You have two more bugs for fix today and you'll be lucky if you're home by midnight and see your wife or kids. You've been stuck in the office and haven't seen them in days.
Are you an "idiot", "talentless" engineer that "deserves to have his software engineering license permanently revoked"? How do you know this wasn't the genesis of this line of code?
When I tried on Linux, it threw a permission error. Turns out Steam installs the folder "~/.local/share/Steam/userdata/[userid]/config/grid" without the executable permission bit. Without this bit no one can create files in there, Steam included, and the custom images feature gets broken.
I reported the problem, saying they should fix their installer, and got a "have you tried reinstalling it?" spiel. When I said I did, and manually changing the permission fixes the problem, so it must really be it, they closed the ticket with "I am glad that the issue is resolved".
This was a ticket at support.steampowered.com, because I didn't know Valve had a github account. I would open an issue there, but I don't have a linux installation to test again and this sort of misunderstanding burns a lot of goodwill.
To be fair to them, when the six-sigma of your customer service is 15 year olds asking to be unbanned cause they totally didn't use hacks, your CS probably gets a bit desensitised.
I know the morale here is keep your files backed up but come on, this is a ridiculous issue Valve still hasn't fixed.
rm -rf "$STEAMROOT/"*
set -u # trap uses of unset variables
Scripting languages in which all variables are defined if you so much as breathe their names are such a scourge ...
I did this once in a build script. It wiped out all of /usr/lib. Of course, it was running as root! That machine was saved by a sysadmin who had a similar installation; we copied some libs from his machine and everything was cool.
set -e # exit on unchecked failure
set -o nounset # set -u
set -o errexit # set -e
set -o pipefail # I'm not sure this has a short form.
I use the long forms for the option names because they're self documenting.
If anyone has more suggestions, I'm all ears.
rm --preserve-root -rf "$STEAMROOT/"*
All system architects ever:
1) System data are sacred, we must build a secure system of privileges disallowing anyone to touch them
2) User data are completely disposable, any user's program can delete anything.
All users ever:
1) What? I can reinstall that thing in 20 minutes, there's like 100 million copies worldwide of these files.
2) These are my unique and precious files worth years of work, no one can touch them without my permission!
Makes me wonder, is there a tool, system, service for auditing how many 'pair of eyes' have reviewed a given line of code. This would be hard to determine, but could be useful. I am envisioning a heatmap bar or overlay that indicates the number of reviews a line of code has received.
It certainly seems that way. CSGO (their FPS) is notorious for updates that break things, like very recently a gun having less ammo than it should, or masks (halloween thing, I think) being rendered through smoke (a crucial feature of the game).
Long ago I had a kernel hack that would kill any process that attempted to delete a canary file. Worked OK but no chance of it ever going mainstream.
I like the 3-2-1 rule:
At least three copies,
In two different formats,
with one of those copies off-site.
Granted, part of the blame lies in the archaic Unix security model which doesn't sandbox applications. But ANY line containing "rm -rf" should be reviewed by the most senior dev in the company, or at least one who actually understands shell scripting. It has such a terrible failure mode, there's no excuse not to. (Especially when the dev to blame knew that it's "Scary!".)
"If it doesn't exist in at least three places, it doesn't actually exist"
- Allan Jude - TechSnap
What does this mean?
The transition from meware to software is a hard one - and usually it's how we get terrible reputations as an industry. Basically it's a prototype till it's burned enough beta users.
Edit OMG - that is actually Steam from valve - I take it back - this is supposed to be software.
# Scary!
rm -rf "$STEAMROOT/"*
Seriously. "xargs rm -df -- < MANIFEST" is not that hard.
EDIT: I shouldn't be so harsh, if it weren't for the comment admitting knowing how poor an idea this line is.
Including my 3tb external drive I back everything up to that was mounted under /media.
Well maybe it was just unfortunate and the drive just happened to be mounted or the "backup" is always online. If it is the latter it is a really bad idea. If your computer is compromised you risk all of your backup. A proper backup should protect your data from these occasions.
rm -rf $1/$2
This horrible, horrible bug lay in wait, until one day the compiler group shipped a patch that looked, felt and smelled like an OS patch that one would add with patchadd(1M) -- but it was in fact a tarball that needed to be applied with tar(1). One of the first systems administrators to download this patch (naturally) tried to apply it with patchadd(1M), and fell into the error case above. She had applied this on her local workstation before attempting it anywhere else, and as her machine started to rumble, she naturally assumed that the patch was busily being applied, and stepped away for a cup of coffee. You can only imagine the feeling that she must have had when she returned to a system to find that patchadd(1M) was complaining about not being able to remove certain device nodes and, most peculiarly, not being able to remove remote filesystems (!). Yes, "rm -rf /" will destroy your entire network if you let it -- and you can only imagine the administrator's reaction as it dawned on her that this was blowing away her system.
Back at Sun, we were obviously horrified to hear of this. We fixed the bug (though the engineer who introduced it did try for about a second and a half to defend it), and then had a broader discussion: why the hell does the system allow itself to be blown away with "rm -rf /"?! A self-destruct button really doesn't make sense, especially when it could so easily be mistakenly pressed by a shell script.
So we resolved to make "rm -rf /" error out, and we were getting the wheels turning on this when our representative to the standards bodies got wind of our effort. He pointed out that we couldn't simply do this -- that if the user asked for a recursive remove of the root directory, that's what we had to do. It's a tribute to the engineer who picked this up that he refused to be daunted by this, and he read the standard very closely. The standard says a couple of key things:
1. If an rm(1) implies the removal of multiple files, the order of that removal is undefined
2. If an rm(1) implies the removal of multiple files, and a removal of one of those files fails, the behavior with respect to the other files is undefined (that is, maybe they're removed, maybe they're not -- the whole command fails.
3. It's always illegal to remove the current directory.
You might be able to imagine where we went with this: because "rm -rf /" always implies a removal of the current directory which will always fail, we "defined" our implementation to attempt this removal "first" and fail the entire operation if (when) it "failed".
The net of it is that "rm -rf /" fails explicitly on Solaris and its modern derivatives (illumos, SmartOS, OmniOS, etc.):
# uname -a
SunOS headnode 5.11 joyent_20150113T200918Z i86pc i386 i86pc
# rm -rf /
rm of / is not allowed
"set -o errexit -o nounset -o pipefail"
It'll save you headaches.
The last option is unfortunately harder to use, since some programs misbehave in pipelines.
set -o nounset (set -u): exit script when it tries to use undeclared variables
set -o pipefail: returns error from pipe `|` if any of the commands in the pipe fail (normally just returns an error if the last fails)
To get the same effect as the "set -o errexit -o nounset", I think you can use "#!/bin/bash -e -u". (There seems to be no option for pipefail.)
bash '-e -u' $file
#!/bin/bash -eu #!/bin/bash
set -eu
IFS=$'\n\t'
$(cd "${0%/*}")And yes, dirname is a way out of this. I'd do this:
"$(cd "$(dirname "$0")"; pwd)"
"the ${0%/*} pulls the path out of $0, cd's into the specified directory, then uses $PWD to figure out where that directory lives - and all this in a subshell, so we don't affect $PWD"
So for example, that would take /user/amputect/seam_setup.sh and change directories into into /user/amputect.
Since $0 is usually the name of the shellscript itself, this would be trying to obtain the directory path of the shellscript.
Window managers don't make it any easier, and I put a lot of the blame on them for not making it easy to configure applications to start under different users.
One of the users in the Github thread even mentions how SELinux prevented the same thing from happening on his machine.
Spoiler: due to a forgotten space the entire /usr folder was deleted
Part of the scripts installed a bunch of files into what was supposed to be a fakeroot, however I did not have bash's 'set -u' configured and an incorrectly spelled path variable was null, meaning something like: "${FAKEROOT}/etc" was translated into "/etc". Before I realized it, it had clobbered most of my /etc directory.
When the build failed, I was puzzled. I only noticed there was an issue when I opened a new shell and instead of seeing "myuser@host ~]#" I got "noname@unknown ~]#". Uh oh...
Needless to say I know do my development of those scripts from within a VM.
http://www.penny-arcade.com/comic/1999/01/06
Basically, they called delete tree. If the user installed or moved the game to a different location, say, the root, it would delete tree away somebody's whole computer. Fun times.
So if you notice something like this happening, shut down computer asap, so they can't be overwritten. Plug drive into another computer but do not mount it. Instead run some file recovery program on it.
For an SSD it becomes murkier though, what with their trimming and automatic garbage collection.
In the pre and post install deb package scripts there was all kinds of crazy shit, like upgrading grub to grub 2 and manually messing with boot sectors. All this stuff in packages innocuously named modbus_driver.deb or what have you, and all in absolutely the most archaic bash syntax possible. I did suggest, strongly to jail all application binarys that we twiddle around with, with something like chroot, but was rebuffed.
Eventually somebody mixed a rm -rf /bin/* with rm -rf / bin/*, and the rest is history. They bricked about 100 embedded PC's, all in remote locations, all powering powerplant SCADA systems that did stuff like connect to CalISO for grid management or collect billing information. It cost hundreds of thousand of dollars to fix.
if [ -z "$STEAMROOT" ]
# something isnt right... STEAMROOT=$SOME_OTHER_UNSET_VARIABLE/
xargs rm -df -- < MANIFEST
No. "${STEAMROOT}" will contain something when the "rm" command runs. It just might not be what's expected.
> STEAMROOT="$(cd "${0%/*}" && echo $PWD)"
In the pre and post install deb package scripts there was all kinds of crazy shit, like upgrading grub to grub 2 and manually messing with boot sectors. All this stuff in packages innocuously named modbus_driver.deb or what have you, and all in absolutely the most archaic bash syntax possible.
Eventually somebody mixed a rm -rf /bin/* with rm -rf / bin/*, and the rest is history. They bricked about 100 embedded PC's, all in remote locations, all powering powerplant SCADA systems that did stuff like connect to CalISO for grid management or collect billing information. It cost hundreds of thousand of dollars to fix.
SCRIPT="$BASH_SOURCE"
SCRIPT_DIR="$(dirname "$BASH_SOURCE")"Without the slash, an empty variable would result in a command line of "rf -rf" which would simply fail due to the missing argument.
There is absolutely no need for having a trailing slash, it's not as if "rf -rf foo" and "rm -rf foo/" can ever mean two different things, there can be only one "foo" in the file system after all.
Very interesting way of introducing an epic fail with a single character, that really looks harmless.
If a doctor accidentally removes the wrong organ because administrators have overscheduled him, "whoopsie, not my fault" is not the appropriate answer. The same applies to engineers working on bridges. Professionals take responsibility for their working conditions.
There is an enormous shortage of programmers right now. Anybody shipping stuff that is bad or dangerous is choosing that. If we drop our professional standards the moment a boss makes a sadface, then we're not professionals.
If they have not internalized the consequences of the risks they're asking their subordinates to take, they'll weigh what look like vague misgivings about "mumble, should be better, dangerous, blah blah" against the better understood risk of their bonus disappearing if the product doesn't ship on time.
Even if you choose to sacrifice yourself, your reputation, and your future prospects--again, if almost no employer in your industry would value what you call professionalism over short-term profits--someone else will ship the code you wouldn't.
That isn't a defense of anything; it's just a fact. Taboos (e.g. against bad code) don't work if they're not shared by the majority.
Incidentally, that sort of thing does happen sometimes.
http://www.cnn.com/2010/HEALTH/10/18/health.surgery.mixups.c...
I'd rather take the first option. At least my reputation will still be somewhat intact.
And as a bonus, I can get out of that hostile environment earlier.
I'd take the same option, but for different reasons: the customer's data. Only pictures of e.g. a deceased wife, no backup, and you just deleted them. You can arm-wave all you like about backing up, but you deleted them.
This is the reality of corporate development. I think we should be demanding more before buying software from vendors, especially when you can't just whip out the source code to audit or fix yourself.
Suff like this doesn't have to happen, but we let it.
Valve doesn't have bosses, remember?
Pushing in shitty broken means you're not doing your job. If your company forces you to do this then they are not doing their job.
Also: backups. I know it sounds cliche, but look, if it has a mechanical hard drive, the manufacturer could have slightly mis-calibrated one of the mechanical assemblies, and this could have happened because the nature of digital storage is that it is essentially ephemeral.
Protect yourself from things outside your control. You don't need the most sophisticated solution, just an external usb drive.
For this reason, the recommened way to use things like rsnapshot is to have your backup directories owned by root and with permissions masked to something like rwxr--r--. If you then want to read your backups easily, you do things like mount it under NFS as read-only.
Just ARQ and an AWS Account [or google drive, or dreamobjects, or SFTP, or...].
Your backup is client side encrypted and completely painless. Take half an hour to set it up and then just forget it till it saves your ass.
Not affiliated, just a fan: http://www.haystacksoftware.com/arq/
The other problem here is the concept that commercial software should be held to some higher standard of liability than noncommercial software. If some random group of strangers build a bridge, which then collapses and kills someone, they're still very much open to lawsuits. So far, the programmers of the world have fended this off by shouting in all-caps about warranties express or implied -- but eventually (I hope) the world will get sick of their shit and hold them accountable for failure. When that happens, whether or not the software is sold should have nothing to do with damage liability (outside of any sale contracts that my apply).
A man can dream.
Of course once it was a identified a concerted effort could have been made to rectify the situation.
Sometimes a problem is identified working on some unrelated aspect of the software and the developer does not have time or scope to change the offending piece of code but wants to place a red flag.
Of course this example does not appear to be systematic approach to marking "fixme", unless of course their fixme tag is actually #scary.
Edit: Of course one would hope they have raised a rather high priority work item for this.
The issue is that this particular script did not set up $STEAMROOT correctly.
Sure, you could somehow check that STEAMROOT is set to something resembling what you want to delete. But manifests are much more simple to get right.
EDIT: Alternatively, pick a well-known UUID, and put everything under a directory with that name under STEAMROOT. Then, to remove:
rm --one-file-system -rf "$STEAMROOT/d0a8936d-1faf-4b82-aac9-e5f104432b24"
(Don't put the UUID in a variable, or you're back to square one of having a potential bug!)
rm -rf $the_dir && mkdir $the_dir
Bryan--you mean Star Trek didn't get it right? Well, at least they didn't allow shell scripts.
It's an interesting philosophical question though. At what point do you decide that the user truly really can't want to do this even though they've said that they do?
A real self-destruct button would ensure you couldn't recover the data anymore.
So at least try "dd if=/dev/random of=/dev/sda" or more elegant when available, throw away the decryption key.
rm -rf /*
Edit: I just noticed that the glob operator in my first comment didn't show up, because it was eaten by markdown. Incidentally, so was the asterisk in your post! That might be the source of your confusion. In that case, I should specify such a trick only works with:
rm -rf *
rm -rf /*
rm -rf ~/*
As an aside, the context of this post is a mistake in steam.sh which may essentially do:
rm -rf /*
I actually separated Steam into a sand-boxed "steam" user account. But maybe that's because I learned Unix on BSD and never included SELinux or how to use it (and it isn't obvious from a desktop user accounts perspective), I should probably check that out.
That's true, but the original code was akin "rm -rf foo/*" and that's different, since it removes the content of the directory while preserving it.
This behavior is especially common with regards to URLs; there are many flamewars about whether URLs “need” a trailing slash or not.
The only complaint here is about the app store, sandboxing is wonderful.
Maybe there were time constraints. Maybe the coder explained that this code was dangerous to his boss but was not grantee the time to fix it.
I think we agree that said code should never have been written, but there are any number of circumstances that place the blame squarely on management. If he explained the dangers of doing it that way but wasn't granted time to fix it (or no manifest was kept), theres little that johnny coder can do outside of their own time.
None of us write perfect code the first time, and we all had to start somewhere. What's important is how far youve come and what you've learned. I think.
Speaking only for myself, I've seen it with internal git repos at companies that have some name recognition. Obviously they'd never want it known that this happens, but it does.
So why does it happen? In the cases I saw, it was usually when people responsible for code reviews had "other things on their plate", and rather than hand off the review to someone else, they just merged it. During heavy pushes to get a build out the door, I saw a lot of this happening. Since I never said anything, I suppose I was part of the problem.
Converting sunlight to electricity is a solved problem. The "energy crisis" remains unsolved.
Jailing processes is a solved problem. Preventing users from shooting themselves in the foot remains unsolved.
Now let us reexamine the post:
> ...would be a helpful thing to build into modern operating systems...
Already built in.
> Why can’t we also have something analogous where different files or other system resources are only accessible to applications that have been approved for that access?
We do. Solved problem. Now if we want to prevent users from shooting themselves, that is a different problem.
That last paragraph sure makes it sound like the writer is unaware of these solution's existence... but let us suppose that he knows about them and is coming at it from your perspective. In that case I agree, we don't have a solution in place - and I'd love to see one in common use. I'd think you'd be able to implement such a system through package management for the majority of software, an added chroot step. That is why I included distro and application devs in those that share blame for the problem. Users are also included, to a smaller degree, because this is a known problem with a known solution.
I'm not sure Emacs or vim, as an example, would ever be able to be sandboxed from the filesystem.
A MANIFEST is not the right answer. Steam deals with any number of third-party games which may drop any number of files into these directories.
The best way to nuke a directory is 'rm -rf "$DIRECTORY"'. Any amount of "well what if $DIRECTORY points to the wrong place" has nothing to do with the removal operation itself.
Shell scripting seems tremendously overused. It makes some things a bit easier, but it's so crazy it makes PHP a look like a pinnacle of good language design.
I'll probably get flak for this, but for 99% of the scripts, at this point I'd just use bash. Linux has it as a default, as does Mac OS, anyone running BSDs can install it trivially, and Unixes probably have it as well since most of them have antiquated CLI environments and administrators usually install GNU utils to have a more human working environment.
http://pubs.opengroup.org/onlinepubs/009695399/utilities/set...
"-u The shell shall write a message to standard error when it tries to expand a variable that is not set and immediately exit. An interactive shell shall not exit."
Disk scanning programs like DaisyDisk from the app store have to make you do this before they can get any information about disk usage.
Some systems mentioned in this HN discussion are closer to the kind of model I had in mind. As other posters have pointed out, the difficulty is how you structure a system so that it is reasonably effective by default but still usable by non-experts. I believe we could achieve this — or at least get much closer than the typical security models we use at the moment — but it will surely take a lot more thought and experimentation than we have attempted as an industry so far. Microsoft’s UAC mechanism makes an interesting case study here: it was fundamentally a reasonable idea, but the first implementation proved too intrusive for average users to tolerate and lost much of its effectiveness as a result.
[0] http://en.wikipedia.org/wiki/L4_microkernel_family#High_assu...
One would be analogous to an ACL arrangement rather than simple ownership. Steam applications could be installed with Steam also having permission to access their resources.
A second possibility would be to have the operating system provide dedicated services for installing and maintaining software. We’re already heading in that direction on some platforms anyway, and it would be useful generally given the kind of security model I suggested. Then software like installers/updaters or package managers can do their jobs in a tightly controlled way, without needing any general access or introducing the accompanying security risks.
I can count the times I've been owned through an app that doesn't run content from the internet (either accessed by or being a server for) on zero hands.
What is the problem that sandboxing every app into a homogenous set of thou-shalt-not's solves?
In software, if I build a toy, and release it to the world, many people may find it useful. They might trust it with their most personal data, or vital business documents. But, it is still a toy.
If I build a toy bridge no-one tries to make it span the grand canyon. They see it for what it is - its faults are obvious. They try to cross my toy bridge and it easily collapses under the weight of their foot without costing the lives of anyone. And, if they somehow managed to string along my toy to the point where it could span the grand canyon, do you think anyone in their right mind would find me liable as the toy maker?
Ultimately, this is where the differences are huge. People are building toy bridges, pet bridges, foot bridges, bridges for single cars and bridges for 10 lanes of traffic. It's very difficult to accidentally substitute a bridge built for 1 person into a spot you need a bridge for 10 lanes of traffic.
But it's trivial in software to put a "toy bridge" or "pet bridge" where you need something like the golden gate bridge.
So, when someone takes my toy and tries to use it as the golden gate bridge, whose at fault?
With a bunch of random people just making a bridge that collapses, then unless it's on their own property, they know that other people will use it and expect it to not collapse and so liability is justified there. (If it's on their own property, then morally there shouldn't be any liability unless they invited someone to use it, but legally is another matter.)
If this was ANY product other than software, there wouldn't even be a question of Valve being liable, and that's just disgusting to me.
I think the problem is EULAs. Foss Eula's are pretty straight forward - no warranty: use at your own risk. Corporate software takes the same approach, and I think that's cowardly and underhanded because they are a profit driven entity which, if not incentivized properly, would literally rob you blind.
Corporations are profit driven. No profit, no corporation.
If your going to profit off of selling me something which then burns my house down because it was cheaper for the vendor to not build to standards (best practices), shouldn't they be held liable?
If someone made a lamp for themselves that wasn't up to standard, and then left it out on the curb for garbage pickup when you came along and took it home, plugged it in, and burned down your house, who's fault is that? They didn't sell it to you. There was no purchase.
And you seem to have missed the part where I explicitly said that both commercial and noncommercial software should be exposed to liability lawsuits. EULAs are a waste of everyone's time: anything distributed in an executable format should expose the distributor to liability suits for damages.
And now the creator of the instructions is liable for damages? Wait, what?
For what it's worth, I didn't miss that part, I just disagree with it.
But let's explore the idea that anything distributed in an executable format should expose the distributor to liability.
How do you define executable? I mean, what about languages which are optionally compiled, or python or ruby packages for example? And when you say distributor, do you mean distributor or do you mean author? Eg, is Github responsible because they hosted/distributed my code?
By a lot.
No one sane would put a pet project out in the open, and we'd all have far fewer kernels from which great things could grow.
(Unless you're specifically talking about closed-source software, in which case I just might largely agree with you.)
Yeah, we've all noticed the rampant mass deaths of millions because of software issues...
/sarcasm
Yes, of course. We take such decisions everyday. Cars lead to deaths from traffic accidents, and still we are ok with it as a necessary evil, since we want the benefits they provide.
If we restricted technology to "things that can cause absolutely no deaths" we would even have used fire (tons of people die every year from it). Heck, houses too can collapse in an earthquake etc -- we should make sure noone builds one until its 100% safe house (that costs some millions to build).
But my sarcasm was directed at the parent blowing this "deaths due to software" thing out of proportion, and making it sound like someone dies every minute from a buffer overflow.
I don't understand how anyone works in the very unforgiving-of-accidental-delete *nix world without those aliases.
The useless confirmations on every deletion is so intrusive that people will instinctively try to work around it. In the best case they'll undefine those crappy aliases in their own shell config, or maybe gravitate toward writing /bin/rm rather than rm to avoid the alias expansion. In the bad case they'll learn that "rm -f" will override "rm -i", and get in the habit of using that to shut rm up. Too bad that "-f" does more than negate "-i"...
People who don't actively work to circumvent the braindamage will almost certainly end up reflexively teaching themselves to just answer "y" to the prompts without reading. Or worse, they'll learn to depend on the prompts being there, and doing "rm * " when their intent is not to remove everything. "Yeah, I'll just answer 'n' for the files I want to keep". That's going to be a really nasty surprise when they use a machine without that alias.
No. Just no. Don't do it.
The solution in zsh is much better. Warn for "rm * " (or "rm * .o", etc) no matter what, since that's both very dangerous and very rare. But don't waste the user's attention on every single deletion.
… I don't think anyone does that.
Perhaps I should have said "sane systems" ;)
Fedora ships with that alias by default FWIW.
It has the added benefit of being inside the "RHEL/CentOS" ecosystem (similar commands, structure, etc), provides a glimpse of what's-to-come in future releases of RHEL/CentOS, and since majority of servers in the enterprise are RHEL/CentOS based, it's a natural fit.
All that aside -- have you tried Fedora 21? It's a complete overhaul from previous Fedora releases and has a lot to like and offer.
We live in a world where merely installing software might also install a silent updater in the background, or might interfere with existing software that it has no need to touch, or might start monitoring peripherals and phone home with data in ways that could invade privacy. We also live in a world where once popular software, particularly freely available software, sometimes drifts into borderline malware territory over time. In this world, “doing something stupid” can be as simple as turning on your computer and installing (not running, just installing) some of the most popular software in the world today on it.
What is the problem that sandboxing every app into a homogenous set of thou-shalt-not's solves?
To give a few examples, some of us would consider it a bug for everyday applications to splat junk all over a filesystem during a build/install, or to hide data in odd places as part of a copy protection scheme, or to scan a whole disk and automatically upload any files that might support “cheating” in a game to the mothership.
Unlike some here, I am not willing to trust the good intentions of a software developer just because I have paid good money to use their product. Far too many shady practices go on in parts of our industry for that to be a sensible policy without adequate safeguards in place any more.
...there's a commonly misattributed quote I have in mind that describes this situation.
And where do your apps come from? Wasn't there a thread the other day about installing the top apps from download.com and counting the chaos they inflicted on the system? Sure, you can avoid that, but not everyone does.
It's not like an average browser like Chrome where your main use case is running random code from random domains made by random people.
Besides, external apps are non-responsive to the question of whether the tradeoff gained by Apple's variant of sandboxing (where there are certain things you are not ever allowed to do, even if they are integral to the primary purpose of your software) is really worth preventing a limited class of issues?
App store requirements don't stop the user from downloading malware outside of the store. They do stop the user from doing certain things outright, and so push the user outside of the store, and so I'd argue, actually reduce safety as a knock on effect.
I'm sure it works for some but it's not for me.
For GNU xargs I like adding -d\\n which handles everything except files with an embedded newline. Those are much rarer than files with a space, though.
Sadly, OS X xargs (probably BSD based) doesn't have that option, so I have an alias to do the same thing:
alias xargsn="tr '\n' '\0' | xargs -0" rm --preserve-root
It's one of the top aliases in my .bash_aliases file.
Unfortunately dumb lines like "rm -rf $HOME/$STEAMDIR" still get through unscathed.
rm --preserve-root -rf /*
rm: cannot remove ‘/’: Is a directoryNote also that putting a "*" in the MANIFEST doesn't do anything either, as neither xargs nor rm expands wildcards (only bash does).
Its definitely a rube goldberg machine in action.
I feel like the idea of sandboxing its progeny is going to need to look like docker or some sort of container where it appears to be a standard OS (since games use a lot of low level hacks) but is actually partitioned from the rest of the system.