Propose your solution
Attachments
No attachments.
Duplicates
Comments
|
|
"I will most likely encounter this dialog [...] Because the possibility to execute the file or not determined [...] by the rights given to the user towards the file."
Are you saying that your .svg file has +x mode set? Why would you ever do that? If any app did that, then it's the app that's buggy. If you did it yourself, then... what's the problem?
|
alourie
(Idea reviewer)
wrote on the 2 Aug 09 at 06:21
|
|
|
Although I proposed an alternative solution, I still think that this should be handled automatically.
Promoting, and +1 to the both solutions - 1st as generic and 2nd as short term.
|
|
|
@AndrewLuecke:
-- "is a vintage design and is a hack to workaround other problems"
What do you mean? What problems? What exactly do you think is wrong with it - details please...
-- "1) For scripts, all the file locations of the interpretors are hardcoded"
You can always use ever popular:
#!/usr/bin/env python
And you're good to go - it will search your standard exec paths.
-- "2) Linux isn't smart enough to identify an executable file from another one"
Try running `file some file name` ?
-- "It doesn't really add any extra security, because even if you make a user directory Noexec, it can still run bash scripts, perl scripts, python, php, etc. But it happily gives people a sense of false security."
If you have access to bash, perl, python, php, etc. that is. Which you may not have with properly configured permissions + apparmor.
-- "+x does have its uses, but its being used wrong"
Again - what do you mean?
I'm still curious about the original problem - why was that .svg marked +x. Is it a user, or app mistake?
|
|
|
I'm not sure about it... I'm quite happy that I can make anything a script without changing the extension. It's very useful for wrapping real apps system-wide. (for example stuff like adding some preprocessing to apt-get without having to call apt-get-wrapper.py, etc.)
Also, why should anyone care if some program is written in python, perl, or whatever else... If it's executable it can run, if it isn't then you don't run it.
Script don't "need" shbang at the start either. You can run 'xx.pl' if it's executable, or 'perl xx.pl' otherwise.
About the plugins - that's perfectly reasonable. Libraries should not be executable. You don't "run" plugins, you import them. I.e. they should not be marked as executable.
Don't forget it's kernel that does the executable files dispatch, not your userland stuff, so updating this system the way you want would require some serious changes that would be incompatible with posix world...
So yeah - that pretty much leads me to the main point: why would any user care? If they get an application - it is installed as executable and they can run it. If they create documents (in a very wide meaning of "document"), they don't need to make them executable. If anyone creates stuff that is executable, it's programmers and they can deal with writing one line that actually identifies the language...
I can't find any real scenario where a normal user would have to care about the execution rights. Do you?
As a programmer, I'm happy that there is no guessing involved -> if it's executable, then I can execute it and system has strict rules about what happens next (check shbang, or pass to elf / a.out / whatever_was_compiled_in execution path).
|
|
|
"I'm still curious about the original problem - why was that .svg marked +x. Is it a user, or app mistake?"
I hate when I have to manage permissions in my home folder, so I often add a recursive execution right on it.
|
|
|
"I hate when I have to manage permissions in my home folder, so I often add a recursive execution right on it."
I'm sorry, but that completely invalidates your claim about "misrecognised" for me. I'd recommend filling a new idea describing why do you set permissions in that way / what does it resolve and what could be improved, so you don't have to _BREAK YOUR OWN SYSTEM_.
What I understand from this idea is "It hurts when I cut myself." Stop cutting yourself then!
|
|
Lachu
wrote on the 3 Aug 09 at 09:07
|
|
|
|
I think the second rationale paragraph is not true. You can launch LiveCD(or normal system) and create .desktop file on desktop, but without right permissions. What will you seen when click on it? The same question.
|
|
|
|
Please post screenshots in English, otherwise we won't understand them.
|
|
|
@AndrewLuecke:
It doesn't make any sense. "+x" means "executable".
You say: "if a file is accidentally improperly marked, it will be treated as an executable incorrectly. That shouldn't be the case."
Then what should it be treated as? How do you tell a file that was "improperly marked" as executable and one that was "properly marked"? It's starting to get ridiculous... If someone did an action, then the system has every right to assume that it's exactly what he meant.
-- "many developers prefer to use executable self-extracting shell scripts (which have the hardcoded paths in them, and need to be marked +x before)."
How about: run `sh whatever_shell_script` ? Or "open with" -> "bash"?
@mikaelstaldal:
the dialog says:
"Would you like to launch KDE_logo.svg, or display the content?
KDE_logo.svg is an executable text file"
I agree that it should say "... is an image file".
|
|
andruk
(Idea reviewer)
wrote on the 4 Aug 09 at 04:52
|
|
|
|
I agree with AndrewLuecke.
|
|
|
+1 AndrewLuecke
[quote]Either way, its totally lame that marking a png file +x, linux thinks it is executable. Why should file permissions affect the way a file is loaded, especially when they aren't always transferred with files?
What if I don't want a binary to be executable? I unmark it and suddenly Linux thinks its a totally different file? AND THATS ACCEPTABLE TO YOU?!? Users would be flabbergasted when their installer turns into a text file. There is no way Microsoft would have succeeded that way. It should be 1 click.. ALWAYS! I think you overestimate users greatly, if you believe that they should be right clicking programs and screwing around to get them running.[/quote]
That's basically what I meant with solution #1!
Do I have you permission to change it's description for what you said?
|
|
|
I demoted soultion #1 since I don't want to increase the risk that a user execute some malware by accident.
However, I understand the problem and came up with an alternate solution (#4): when a file is associated with an application, Ubuntu should ignore any executable attribute and open the file with the associated application anyway.
That solution should not open any security holes.
|
|
|
-- "Either way, its totally lame that marking a png file +x, linux thinks it is executable. Why should file permissions affect the way a file is loaded, especially when they aren't always transferred with files?"
I really don't see anything wrong about executable .png. It's just a name.
The fact that permissions are not transferred via http, or other means is a "good thing". Think about many classes of problems that affect Windows (which you give as an example here). Pseudo-executable .lnk files, .scr viruses, double extension tricks, viruses in help files, embedding "standard word document" icons in executables, etc. These basically don't exist in unix world. Exactly because you cannot just do a "1 click" run.
-- "What if I don't want a binary to be executable? I unmark it and suddenly Linux thinks its a totally different file? AND THATS ACCEPTABLE TO YOU?!?"
No, it's the same file, without execution rights. Yes, it makes perfect sense to me.
-- "Furthermore, in 5 years time when /usr/bin should no longer exist"
It might have been someone's random decision that one day they put sh in /bin. But it won't be a random decision to remove it, and efforts like freedesktop, lsb, etc. mean that it won't be removed for decades in any sensible distros. If it will be moved somewhere, then there will be a link put in the same place for backwards compatibility. That's why you can take /bin/sh for granted. Noone is so insane as to remove it, when it's got so many scripts depending on it.
Solution 4 also isn't that great. Executable scripts may well be documents associated with an application. Any text file may be an executable and a normal text file at the same time. That's why we've got the current mechanism - asking. .svg files should never have +x on them - if that's true, they are simply opened without any questions.
|
|
|
'Linux isn't smart enough to identify an executable file from another one, so the +x is to tell it its one.' - AndrewLuecke
Completely incorrect, filetype can be found using the command 'file -ib' as so:
$ file -ib script
text/x-shellscript
|
|
viraptor
wrote on the 30 Aug 09 at 10:09
|
|
|
Just a couple of corrections. #! has been a standard way to handle scripts since ~1980 (BSD roots - that's ~30 years now). You can hardly say it's not the standard way, even if it hasn't been written down as such. (I suspect that POSIX and BSD documents include it anyways - if someone is interested enough he can look it up)
It's useful in a couple of situations - custom interpreters and multiple version. If you need a custom patched version of an interpreter you can still deploy a script that will be runnable and people don't have to care about the details. You just add a #!/usr/local/my_hacked_perl/bin/perl to that one script.
The second scenario is similar - you may want one script to invoke /usr/bin/python2.5 and another to invoke /usr/bin/python2.6 (will be even more useful with 3.0 as they have the same extension, but incompatible format).
Allowing #!perl would be dangerous. If you can somehow get a perl file into a place that's in admin's $PATH, then you can hijack his session the next time he runs a perl script - that's a no-no.
Why not magic extensions? If you have translated files, they're usually named like base_file.ext where ext is the iso short name of a country I wouldn't want polish translations of anything to by run with perl by default.
The only "sane" way I can see that would solve your problem of portability is to propose a new magic word like "with", so that "#!with perl" could use a default perl binary in the system, looked up in a system-specific way. (that could include some funky stuff like "#!with python >=3.0")
|
|
viraptor
wrote on the 30 Aug 09 at 17:15
|
|
|
"So you wanna claim that the unix standard encompasses all scripting formats too?"
No. But the way executable files are loaded into the new process -> yes.
Otherwise I agree with you. It's still needed to select an interpreter version (perl 5 and 6 are not compatible, neither are python 2.5 and 3.0). Something more customisable would be cool (I'm for the #!with ...) not sure what are others' opinion on that.
The argument about insecure binaries were given most of the time... I also don't really care about it, but some people will swear by that for some reason - does anyone know why?
|
|
|
I can't stop asking myself why do you (viraptot) keep making the devil’s advocate.
About the insecure binairies...
Well, this is not more of a problem than those "rm -rf /*" that we may sometime see on the forum. In fact, this will always be a minor issue, since you need some programming skills to make reals binairies and for the scrips...
There's surely a solution.
|
|
viraptor
wrote on the 31 Aug 09 at 13:42
|
|
|
I don't play devil's advocate. I simply state my opinions / concerns. I really enjoy working with unix permission system and the way scripts are executed now. I think that extensions are a failed concept (appending a mime type + version though... that would be fun).
There are places where I think it could be better, that's why I wrote about the idea I was playing with for some time: #!with
Still - this is not really an idea about execution, but rather filetype detection. Solution #2 solves the person's problem, even if it was his own fault that caused it.
|
|
|
|
Well, I added a new solution (which I really like), but it looks like we ABSOLUTELY need to post a comment to effectively bump an Idea...
|
|
|
How does Solution #7 differ from solution #4?
|
|
|
|
#7 supports the fact that you may either want to execute, or edit the file, but still remove the use of the window.
|
Post your comment
|
