Hi, Am Montag, den 09.05.2005, 20:10 +0100 schrieb Mike Hearn: > Hi, > > I'd like to request that Nautilus be modified to run shell scripts even if > they don't have the +x bit. There are two parts to the rationale: > > 1) The +x bit adds no security. It can be trivially bypassed by simply > enabling it in the UI, or by copy/pasting something into the command yes, copy/pasting and adding some non-trivial text, that is. I'd say that's pretty hard to do "accidentially" > line. Once the user has made a decision to run a program, the desktop > should not make people jump through arbitrary hoops, it should just do > it "the user has made a decision to run a program" is only half the story. If it doesnt have +x, it _is no program_. If it nevertheless appears as a program to the user, now _that_ would be a serious problem :) Well, no matter if it adds security or not. The point is that program is +x, while a non-program is -x. This shouldnt be a difficult concept to grasp for even the most rookie users. (famous last words...) And as for now, shell scripts *are* only recognizable as executable program by the +x flag (hmm ok, and maybe the shebang, if available at all). I think the root cause is the browser not flagging the shell script as executable (the browser should check that and just ask if it should add +x, really - maybe use a special mime type for shell script transfer so it is obvious without having to download the file first) Something like this should be opened at www.freedesktop.org to make it standard. Feel free to add it (please do) > > 2) More pragmatically, Codeweavers is getting more and more users who > file support tickets along the lines of "I bought your product but > nothing happens when I click the installer!". A few years ago we got > one of these maybe every few months and they were just a curiosity, > but as Linux has become easier to use we're getting many more > non-technical users (yay!) to whom UNIX foibles like the +x bit are > alien. Sanding off this usability rough edge would reduce our workload > a bit. But I see what you are getting at. There are some kinds of "inconsistencies" that can happen to files when they are e.g. downloaded (or run from a iso9660-without-rockridge cdrom ?): - exec bit is lost - permissions are lost - extended attributes are lost for downloads there is additional data arriving that is more or less discarded: - mime type I do think that providing some "unbreak me please" dialog in nautilus is a suboptimal way of doing things. Better fix up the root cause (i.e. non-rockridge cdroms not having a 'standard' way of marking unix executables, and app 'package' downloads not having a immediate-extract file format) > > Here are some common objections so I can try and swat them before things > turn into a full-on flamewar :) > > Q: "The +x bit is the UNIX standard security system, we shouldn't ignore > it" > A: Of course we should, GNOME already tries to hide the UNIX FHS and > other scary bits of traditional UNIX geekery. This is no different. I'd say if you want it so bad (without fixing the root cause of the browser not +x-ing the file), add a special file extension and make nautilus execute it no matter what (like "xyz.suspicious" - I'm not entirely kidding about this filename extension to use - people will get used to it, so better make it something very unsettling :)) > > Q: What about noexec mounts? > A: Users can already circumvent the noexec bit for shell scripts anyway, > so it makes no difference. I'd say then that (which makes them able to circumvent the noexec bit easily) would be a bug. What is it ? > > Q: If users can download and run stuff easily Linux will be full of spyware > A: They already can, and the process of enabling the +x bit adds no > additional information to what the user already has so it won't affect > their decision to run the program. If we want to build some > quarantining/blacklist system then that is a whole other topic, which > is orthogonal to this one. > > Q: Why don't you just ship the installer in a tarball? > A: Because this is lame, adds additional complexity for users who already > have too much, and is working around the desktop not being easy to use > instead of fixing it That depends on how tarballs are handled. MacOS9 (which I have on my very very old powermac here :)) does it that way: Whenever you click on a stuffit archive, it will automagically (and instantly) get extracted into the current directory into a new subfolder (and when I started using macos after using windows first I went "HUH?! Why doesnt a window/app appear" but about two seconds later I saw the new folder that appeared - plus, if the extractor program notices that there already is a folder, it could say "Hey lookie there, there is a folder, maybe you already clicked on the tarball") I dont see how that could get difficult to use at all, ever. Please do tell me how :) Plus, just have the browser check the mime type of the shell script that will be downloaded and figure out that it should +x it, I can't see any shortcoming with that (ok, other than it adds a confirmation dialog to the download process - which could be considered a good thing). > > Q: Why do you ship self-extracting installers instead of DEBs/RPMs/Slackpacks/etc? > A: Because users seem to prefer them, and because many distros aren't set > up to graphically install RPMs/DEBs/whatevers when clicked on. yeah > > thanks -mike > cheers, Danny -- www.keyserver.net key id A334AEA6
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil