From: Jun O. <ok...@di...> - 2005-10-26 10:59:19
|
Hello. Can I ask you a very beginner question here? ( Yes, I am totally beginner of ROX). I can not find out how to use "run action". I did a trial like below, and what is wrong?. --- Okajima, Jun. Tokyo, Japan. ----- 1-4 are okay, but 5 is the problem. 1. make sample.sh with +x attribute. the contents is just like this: #!/bin/sh echo ARGS: $@ 1>&2 2. Set "Run Action" as this. /bin/bash "$@" 3. When it runs well as a normal command. like $ ./sample.sh a b c ARGS: a b c 4. If I click the sample.sh from ROX, it runs. 5. But, When I drop other file to the script, nothing happen. An icon of data file seems to be rejected, because it shows an animation of returning. WHY? |
From: Brandin C. <cha...@ya...> - 2005-10-26 13:32:19
|
--- Jun OKAJIMA <ok...@di...> wrote: > I can not find out how to use "run action". > I did a trial like below, and what is wrong?. > > 1. make sample.sh with +x attribute. > the contents is just like this: > #!/bin/sh > echo ARGS: $@ 1>&2 > > 2. Set "Run Action" as this. > /bin/bash "$@" Here is the problem. The concept of "executable" (as in 1) supports dropping icons. But using "Set Run Action" does not allow dropping icons. (1) and (2) cannot be used at the same time. Basically, you have two options: 1. Rename your script so that it doesn't end in '.sh'. 2. Configure ROX to not ignore the executable bit for known extensions (ROX-Filer -> Options -> Types) __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com |
From: Jonatan L. <th...@ho...> - 2005-10-26 18:01:29
|
On Wed, 26 Oct 2005 06:31:57 -0700 (PDT) Brandin Creech <cha...@ya...> wrote: > 1. Rename your script so that it doesn't end in '.sh'. > 2. Configure ROX to not ignore the executable bit for known > extensions(ROX-Filer -> Options -> Types) Which reminds me, why was this option taken out in 2.3 ? I have lots of shell scripts that does NOT end with '.sh', and have the executable bit set, but ROX won't recognize them as executables. It's very disturbing. I consider it a bug. Also ascii-files have begun to be regognized as "octetstream", just becouse there are some 8-bit chars in them (iso8859-1 encoding), this was not happening before. The "file" commandline utility reports it correctly: ]file -i SomeFile SomeFile: text/plain; charset=iso-8859-1 /Jonatan -=( http://kymatica.com )=- |
From: Keith W. <kr...@va...> - 2005-10-26 18:58:13
Attachments:
foo.sh
|
* <th...@ho...> [26/10/2005 1418EDT]: > On Wed, 26 Oct 2005 06:31:57 -0700 (PDT) > Brandin Creech <cha...@ya...> wrote: > > > 1. Rename your script so that it doesn't end in '.sh'. > > 2. Configure ROX to not ignore the executable bit for known > > extensions(ROX-Filer -> Options -> Types) > > Which reminds me, why was this option taken out in 2.3 ? > > I have lots of shell scripts that does NOT end with '.sh', and have the > executable bit set, but ROX won't recognize them as executables. It's > very disturbing. I consider it a bug. Also ascii-files have begun to be > regognized as "octetstream", just becouse there are some 8-bit chars in > them (iso8859-1 encoding), this was not happening before. The "file" > commandline utility reports it correctly: Hmm... is this executable problem somehow related to extended attributes? I'm using ROX-Filer 2.3 on a 2.6.13.4 kernel with ext3 filesystems, without extended attributes and do not have this issue. An executable shell script, with or without the .sh extension, gets recognized properly as application/x-shellscript. This is also w/ shared-mime-info 0.16. As for the 8-bit stuff, consider the attached foo.sh. On my system, clicking on it in the filer runs it but it blows up for other reasons: the script just writes to stderr, which is captured by ROX-Session. Pango, via ROX-Session, complains that it's been passed invalid UTF-8. :/ Keith -- SA Valaran Corp GPG: 0xEC705AE9 I put the sh in IT. s/^\(I\)\(T\)$/\1sh\2/ |
From: Jonatan L. <th...@ho...> - 2005-10-26 19:06:55
|
On Wed, 26 Oct 2005 14:58:06 -0400 Keith Warno <kr...@va...> wrote: > * <th...@ho...> [26/10/2005 1418EDT]: > > On Wed, 26 Oct 2005 06:31:57 -0700 (PDT) > > Brandin Creech <cha...@ya...> wrote: > > > > > 1. Rename your script so that it doesn't end in '.sh'. > > > 2. Configure ROX to not ignore the executable bit for known > > > extensions(ROX-Filer -> Options -> Types) > > > > Which reminds me, why was this option taken out in 2.3 ? > > > > I have lots of shell scripts that does NOT end with '.sh', and have > > the executable bit set, but ROX won't recognize them as executables. > > It's very disturbing. I consider it a bug. Also ascii-files have > > begun to be regognized as "octetstream", just becouse there are some > > 8-bit chars in them (iso8859-1 encoding), this was not happening > > before. The "file" commandline utility reports it correctly: > > > Hmm... is this executable problem somehow related to extended > attributes? I'm using ROX-Filer 2.3 on a 2.6.13.4 kernel with ext3 > filesystems, without extended attributes and do not have this issue. > An executable shell script, with or without the .sh extension, gets > recognized properly as application/x-shellscript. This is also w/ > shared-mime-info 0.16. Well, all my shell scripts are recognized as application/x-shellscript, with or without the .sh extension and it ignores the executable bit. So they are not executable, I can't click them or drop stuff on them. /Jonatan -=( http://kymatica.com )=- |
From: Brandin C. <cha...@ya...> - 2005-10-26 20:45:51
|
--- Jonatan Liljedahl <th...@ho...> wrote: > On Wed, 26 Oct 2005 14:58:06 -0400 > Keith Warno <kr...@va...> wrote: > > > * <th...@ho...> [26/10/2005 1418EDT]: > > > On Wed, 26 Oct 2005 06:31:57 -0700 (PDT) > > > Brandin Creech <cha...@ya...> wrote: > > > > > > > 1. Rename your script so that it doesn't end in '.sh'. > > > > 2. Configure ROX to not ignore the executable bit for known > > > > extensions(ROX-Filer -> Options -> Types) > > > > > > I have lots of shell scripts that does NOT end with '.sh', and have > > > the executable bit set, but ROX won't recognize them as executables. > > > > An executable shell script, with or without the .sh extension, gets > > recognized properly as application/x-shellscript. This is also w/ > > shared-mime-info 0.16. > > Well, all my shell scripts are recognized as application/x-shellscript, > with or without the .sh extension and it ignores the executable bit. A file being "executable" is distinct from it being having a type of "application/x-shellscript." Also, a file on a UNIX system can be executable no matter what it contains as its first two characters or its magic number. Being "executable" refers to the filesystem permission bit (as in chmod a+x) that gets set to allow you to execute a program directly (as by typing the filename at a shell prompt). I'm using ROX 2.2.0, and I have tested on filesystems with user_xattr and without. Here is how ROX-Filer determines the file type. Note that during the directory scan, ROX never looks at a regular file's actual contents to determine its type: 1. If the file has its "executable bit" set, ROX-Filer considers it as "executable" and ignores its type. File type determination finishes. If ROX-Filer is configured to ignore the executable bit for known filetypes, skip to step 2. 2. If there are extended attributes on this file, look for a key 'user.mime-type' and read its value. If it is a valid mime type, ROX-Filer considers it as that type (regardless of the file extension), and file type determination finishes. 3. ROX-Filer looks for a known file extension, and tries to match the extension against its database of file extension->mime-type mappings. If a match is found, ROX-Filer considers the file to be that type; file type determination finishes. 4. If ROX makes it past the first 3 steps, and if the setting "ignore executable bit for known filetypes" was set, then at this point, ROX will consider a file with its executable bit set an "executable" and file type determiniation finishes. 5. If ROX has still not determined how to treat the object, ROX-Filer considers it a "text file." Done. Only objects which ROX-Filer considers "executable" allow dropping files onto them. Dropping a file object onto an executable object is equivalent to typing the name of the executable at a shell prompt with the dropped object as an argument. Also, double-clicking an executable objects is the same as typing the filename at a shell prompt with no arguments. Therefore, if ROX-Filer does not consider the object "executable," it is considered to be something else such as 'audio/mpeg' or 'application/x-shellscript', and these objects show a special icon to indicate their type. They also run a special program (The run action) when double-clicked, but they do not allow accepting dropped objects. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com |
From: Jonatan L. <th...@ho...> - 2005-10-26 23:41:18
|
On Wed, 26 Oct 2005 13:45:41 -0700 (PDT) Brandin Creech <cha...@ya...> wrote: > --- Jonatan Liljedahl <th...@ho...> wrote: > > > On Wed, 26 Oct 2005 14:58:06 -0400 > > Keith Warno <kr...@va...> wrote: > > > > > * <th...@ho...> [26/10/2005 1418EDT]: > > > > On Wed, 26 Oct 2005 06:31:57 -0700 (PDT) > > > > Brandin Creech <cha...@ya...> wrote: > > > > > > > > > 1. Rename your script so that it doesn't end in '.sh'. > > > > > 2. Configure ROX to not ignore the executable bit for known > > > > > extensions(ROX-Filer -> Options -> Types) > > > > > > > > I have lots of shell scripts that does NOT end with '.sh', and > > > > have the executable bit set, but ROX won't recognize them as > > > > executables. > > > > > > An executable shell script, with or without the .sh extension, > > > gets recognized properly as application/x-shellscript. This is > > > also w/ shared-mime-info 0.16. > > > > Well, all my shell scripts are recognized as > > application/x-shellscript, with or without the .sh extension and it > > ignores the executable bit. > > A file being "executable" is distinct from it being having a type of > "application/x-shellscript." Also, a file on a UNIX system can be > executable no matter what it contains as its first two characters or > its magic number. Being "executable" refers to the filesystem > permission bit (as in chmod a+x) that gets set to allow you to execute > a program directly (as by typing the filename at a shell prompt). Yes, of course. The problem is that rox 2.3 ignores the executable bit, and the option seems to be taken out since 2.2. Anyhow, even if it ignores the exec bit for known types, it should treat application/x-shellscript (especially those that DO have +x) as executables. With 2.3 (for me at least) there's no way to handle shellscripts as executables. /Jonatan -=( http://kymatica.com )=- |
From: Brandin C. <cha...@ya...> - 2005-10-27 00:26:52
|
--- Jonatan Liljedahl <th...@ho...> wrote: > Brandin Creech <cha...@ya...> wrote: > > > --- Jonatan Liljedahl <th...@ho...> wrote: > > > > > Keith Warno <kr...@va...> wrote: > > > > > > > > Brandin Creech <cha...@ya...> wrote: > > > > > > > > > > > 1. Rename your script so that it doesn't end in '.sh'. > > > > > > 2. Configure ROX to not ignore the executable bit for known > > > > > > extensions(ROX-Filer -> Options -> Types) > > > > > > > > > > I have lots of shell scripts that does NOT end with '.sh', and > > > > > have the executable bit set, but ROX won't recognize them as > > > > > executables. > > > > > > > > An executable shell script, with or without the .sh extension, > > > > gets recognized properly as application/x-shellscript. This is > > > > also w/ shared-mime-info 0.16. > > > > > > Well, all my shell scripts are recognized as > > > application/x-shellscript, with or without the .sh extension and it > > > ignores the executable bit. > > > > A file being "executable" is distinct from it being having a type of > > "application/x-shellscript." > > Yes, of course. The problem is that rox 2.3 ignores the executable bit, > and the option seems to be taken out since 2.2. I hvaen't tried 2.3 yet, but I noticed that this property turns off the "ignore executable bit" option: <Option name="display_ignore_exec">0</Option> Try adding that property to the Options key in $CHOICES/ROX-Filer/Options. Replace $CHOICES with your Choices directory (it is $HOME/.Choices on my system, but I think the default is $HOME/Choices). It's possible that ROX 2.3 supports the option, but simply took out the possibility to configure it from the GUI. __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com |
From: Jonatan L. <th...@ho...> - 2005-10-27 10:43:40
|
On Wed, 26 Oct 2005 17:26:41 -0700 (PDT) Brandin Creech <cha...@ya...> wrote: > > > > Well, all my shell scripts are recognized as > > > > application/x-shellscript, with or without the .sh extension > > > > and it ignores the executable bit. > > > > > > A file being "executable" is distinct from it being having a type > > > of"application/x-shellscript." > > > > Yes, of course. The problem is that rox 2.3 ignores the executable > > bit, and the option seems to be taken out since 2.2. > > I hvaen't tried 2.3 yet, but I noticed that this property turns off > the"ignore executable bit" option: > > <Option name="display_ignore_exec">0</Option> > > Try adding that property to the Options key in > $CHOICES/ROX-Filer/Options. Replace $CHOICES with your Choices > directory (it is $HOME/.Choices on my system, but I think the default > is $HOME/Choices). It's possible that ROX 2.3 supports the option, > but simply took out the possibility to configure it from the GUI. No, the option is taken out both internally and from the GUI. /Jonatan -=( http://kymatica.com )=- |
From: Brandin C. <cha...@ya...> - 2005-10-27 14:48:48
|
--- Jonatan Liljedahl <th...@ho...> wrote: > Brandin Creech <cha...@ya...> wrote: > > > > <Option name="display_ignore_exec">0</Option> > > > > Try adding that property to the Options key in > > $CHOICES/ROX-Filer/Options. Replace $CHOICES with your Choices > > directory (it is $HOME/.Choices on my system, but I think the default > > is $HOME/Choices). It's possible that ROX 2.3 supports the option, > > but simply took out the possibility to configure it from the GUI. > > No, the option is taken out both internally and from the GUI. That's annoying. I never use the "display_ignore_exec" option anyway. It's only useful for people with broken mountlines in the /etc/fstab which typically mount fat or ntfs partitions such that they force all files to appear executable. For instance mount -t vfat -o umask=0000 should be replaced by mount -t vfat -o umask=0000,fmask=0111 The second line solves the problem, removing the need to have an "ignore_exec" option. When I have time, I will download rox-2.3.0 and create a patch to fix this "problem." In the meantime, I'm using 2.2.0 and don't see an urgent need to upgrade. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com |
From: Keith W. <kr...@va...> - 2005-10-27 15:04:17
|
* <cha...@ya...> [27/10/2005 1048EDT]: [...] >=20 > The second line solves the problem, removing the need to have an > "ignore_exec" option. When I have time, I will download rox-2.3.0 and > create a patch to fix this "problem." In the meantime, I'm using 2.2.0 > and don't see an urgent need to upgrade. It'd be worthwhile to see first who else has this problem. There's obviously some set of circumstances and/or variables that create this issue and we have yet to determine what that set is. --=20 SA Valaran Corp GPG: 0xEC705AE9 I put the sh in IT. s/^\(I\)\(T\)$/\1sh\2/ |
From: Brandin C. <cha...@ya...> - 2005-10-27 15:21:50
|
--- Keith Warno <kr...@va...> wrote: > [...] > > > > The second line solves the problem, removing the need to have an > > "ignore_exec" option. When I have time, I will download rox-2.3.0 and > > create a patch to fix this "problem." In the meantime, I'm using 2.2.0 > > and don't see an urgent need to upgrade. > > It'd be worthwhile to see first who else has this problem. There's > obviously some set of circumstances and/or variables that create this > issue and we have yet to determine what that set is. If everything I've read is correct, then the issue is simply that rox-2.3.0 has made the "display_ignore_exec" option a mandatory default. The "variable" here is that a user who dislikes the "display_ignore_exec" will be annoyed at rox-2.3.0 because it cannot be disabled. It's really just a matter of preference, but I personally see no need for the "display_ignore_exec" to ever be on. It should default to *off*. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com |
From: Keith W. <kr...@va...> - 2005-10-27 15:42:26
|
* <cha...@ya...> [27/10/2005 1121EDT]: > If everything I've read is correct, then the issue is simply that > rox-2.3.0 has made the "display_ignore_exec" option a mandatory > default. The "variable" here is that a user who dislikes the > "display_ignore_exec" will be annoyed at rox-2.3.0 because it cannot > be disabled. It's really just a matter of preference, but I personally > see no need for the "display_ignore_exec" to ever be on. It should > default to *off*. In my setup the execute bit is not ignored, with ROX-Filer 2.3. If I have a bash script 'foo' and set it to mode 0700, it will execute when clicked on via the Filer, and I can drop arguments onto it. If I rename it to 'foo.sh', it will still be executable via the Filer and I can drop arguments onto it. If I rename it to 'foo.bash', it will still be executable via the Filer and I can drop arguments onto it. If I rename it to 'lkasjdlakjdslakjdkjds', it will still be executable via the Filer and I can drop arguments onto it. If I rename it to 'foo.jpg', then the execute bit is ignored. --=20 SA Valaran Corp GPG: 0xEC705AE9 I put the sh in IT. s/^\(I\)\(T\)$/\1sh\2/ |
From: Ken H. <ke...@ha...> - 2005-10-27 15:51:24
|
On Oct 27, 2005, at 8:42 AM, Keith Warno wrote: > * <cha...@ya...> [27/10/2005 1121EDT]: >> If everything I've read is correct, then the issue is simply that >> rox-2.3.0 has made the "display_ignore_exec" option a mandatory >> default. The "variable" here is that a user who dislikes the >> "display_ignore_exec" will be annoyed at rox-2.3.0 because it cannot >> be disabled. It's really just a matter of preference, but I personally >> see no need for the "display_ignore_exec" to ever be on. It should >> default to *off*. > > In my setup the execute bit is not ignored, with ROX-Filer 2.3. > > If I have a bash script 'foo' and set it to mode 0700, it will execute > when clicked on via the Filer, and I can drop arguments onto it. > > If I rename it to 'foo.sh', it will still be executable via the Filer > and > I can drop arguments onto it. > > If I rename it to 'foo.bash', it will still be executable via the Filer > and I can drop arguments onto it. > > If I rename it to 'lkasjdlakjdslakjdkjds', it will still be executable > via the Filer and I can drop arguments onto it. > > If I rename it to 'foo.jpg', then the execute bit is ignored. THAT is the correct behavior. How'd you do it? :) I wonder if the version of shared-mime-info or presence of gnome-vfs is related to this? |
From: Keith W. <kr...@va...> - 2005-10-27 16:08:57
|
* <ke...@ha...> [27/10/2005 1150EDT]: >=20 > On Oct 27, 2005, at 8:42 AM, Keith Warno wrote: >=20 > >* <cha...@ya...> [27/10/2005 1121EDT]: > >>If everything I've read is correct, then the issue is simply that > >>rox-2.3.0 has made the "display_ignore_exec" option a mandatory > >>default. The "variable" here is that a user who dislikes the > >>"display_ignore_exec" will be annoyed at rox-2.3.0 because it cannot > >>be disabled. It's really just a matter of preference, but I personally > >>see no need for the "display_ignore_exec" to ever be on. It should > >>default to *off*. > > > >In my setup the execute bit is not ignored, with ROX-Filer 2.3. Correction, for clarity: It is not ignored *all the time*. :) Seems to be ignored for file types that shouldn't normally be executable (how many of you have an executable JPEG?). Honesty I think this is lame. If an execute bit is set, regardless of file name, it should be honored and I agree w/ Brandin on this. ROX-Filer should not be going out of its way to fix a mount flaw. >=20 > THAT is the correct behavior. How'd you do it? :) I didn't do anything. It's always been that way. Sorry I didn't make this clear in earlier posts. Granted I update my system quite often with new stuff. This box and the one at home are both built from the ground up, LFS style. Have a look. This is a screenshot of my test. These are all the same file, just different names. The ones that ROX-Filer would execute are colored purple. The ones that a run action would be performed on are colored black: http://valaran.com/~kw/rox/exec.jpg > I wonder if the version of shared-mime-info or presence of gnome-vfs is= =20 > related to this? shared-mime-info here is 0.16. I don't have gnome-vfs installed. My ROX-Filer is built to only depend on gtk+ and its dependencies. This is what I have installed and use daily: gtk+-2.8.6 pango-1.10.0 glib-2.8.3 cairo-1.0.0 atk-1.10.1 ROX_Filer-2.3 ROX-Session-0.1.25 And my locale settings are equally simple: LANG=3D LC_CTYPE=3D"POSIX" LC_NUMERIC=3D"POSIX" LC_TIME=3D"POSIX" LC_COLLATE=3D"POSIX" LC_MONETARY=3D"POSIX" LC_MESSAGES=3Den_US LC_PAPER=3D"POSIX" LC_NAME=3D"POSIX" LC_ADDRESS=3D"POSIX" LC_TELEPHONE=3D"POSIX" LC_MEASUREMENT=3D"POSIX" LC_IDENTIFICATION=3D"POSIX" LC_ALL=3D although I'm not sure how the locale would play a role. --=20 SA Valaran Corp GPG: 0xEC705AE9 I put the sh in IT. s/^\(I\)\(T\)$/\1sh\2/ |
From: Ken H. <ke...@ha...> - 2005-10-27 16:52:04
|
Keith Warno wrote: > * <ke...@ha...> [27/10/2005 1150EDT]: > >>On Oct 27, 2005, at 8:42 AM, Keith Warno wrote: >> >> >>>* <cha...@ya...> [27/10/2005 1121EDT]: >>> >>>>If everything I've read is correct, then the issue is simply that >>>>rox-2.3.0 has made the "display_ignore_exec" option a mandatory >>>>default. The "variable" here is that a user who dislikes the >>>>"display_ignore_exec" will be annoyed at rox-2.3.0 because it cannot >>>>be disabled. It's really just a matter of preference, but I personally >>>>see no need for the "display_ignore_exec" to ever be on. It should >>>>default to *off*. >>> >>>In my setup the execute bit is not ignored, with ROX-Filer 2.3. > > > Correction, for clarity: It is not ignored *all the time*. :) Seems to > be ignored for file types that shouldn't normally be executable (how > many of you have an executable JPEG?). Honesty I think this is lame. > If an execute bit is set, regardless of file name, it should be honored > and I agree w/ Brandin on this. ROX-Filer should not be going out of > its way to fix a mount flaw. Hmmm, that is where I was agreeing with the behavior you described below. Don't you think it is a security problem? What is the expected behavior for executing a JPG file? I agree that the Filer should not go out of its way to fix a mount flaw - I do think the Filer should go out of its way to do the right thing (if possible). How about: For executable bit not set: 1) If type has a registered handler use it 2) If type is a 'known executable type' (e.g. shellscript, python?, perl, others?) : a) if ignore=true run it (e.g. do what the type says regardless of the x bit) b) if ignore=false go to the next step (honor the x bit) 3) If no registered handler display message (e.g. current 'No run action specified...') For executable bit set: 1) If type is a 'known executable type' run it, ignoring any handler (e.g. if you like -x shellscripts to be opened in your editor, but +x to be executed) 2) If type has a registered handler use it 3) If no registered handler and not 'known executable type' (e.g jpeg) display message (e.g. current 'No run action specified...') Q) How do we define 'known executable type'? I don't think shared-mime-info can easily make this distinction. Shouldn't there be an attribute or a whole section in there for this? (e.g. executable/bin, executable/shellscript, etc.) >>THAT is the correct behavior. How'd you do it? :) > > > I didn't do anything. It's always been that way. Sorry I didn't make > this clear in earlier posts. Granted I update my system quite often > with new stuff. This box and the one at home are both built from the > ground up, LFS style. I was kidding. > Have a look. This is a screenshot of my test. These are all the same > file, just different names. The ones that ROX-Filer would execute are > colored purple. The ones that a run action would be performed on are > colored black: > > http://valaran.com/~kw/rox/exec.jpg > > >>I wonder if the version of shared-mime-info or presence of gnome-vfs is >>related to this? > > > shared-mime-info here is 0.16. I don't have gnome-vfs installed. I do, but ldd and a browse through the sources indicate that Filer is not using it. > My ROX-Filer is built to only depend on gtk+ and its dependencies. This is > what I have installed and use daily: > > gtk+-2.8.6 2.6.8 > pango-1.10.0 > glib-2.8.3 2.6.5 > cairo-1.0.0 > atk-1.10.1 > ROX_Filer-2.3 same > ROX-Session-0.1.25 same I don't think pango, atk or cairo are likely issues here. |
From: Brandin C. <cha...@ya...> - 2005-10-27 17:17:38
|
--- Ken Hayber <ke...@ha...> wrote: > > * <ke...@ha...> [27/10/2005 1150EDT]: > > > >>>* <cha...@ya...> [27/10/2005 1121EDT]: > >>> > >>>>If everything I've read is correct, then the issue is simply that > >>>>rox-2.3.0 has made the "display_ignore_exec" option a mandatory > >>>>default. The "variable" here is that a user who dislikes the > >>>>"display_ignore_exec" will be annoyed at rox-2.3.0 because it cannot > >>>>be disabled. It's really just a matter of preference, but I personally > >>>>see no need for the "display_ignore_exec" to ever be on. It should > >>>>default to *off*. > >>> > >>>In my setup the execute bit is not ignored, with ROX-Filer 2.3. > > > > Correction, for clarity: It is not ignored *all the time*. :) Seems to > > be ignored for file types that shouldn't normally be executable (how > > many of you have an executable JPEG?). Honesty I think this is lame. > > If an execute bit is set, regardless of file name, it should be honored > > and I agree w/ Brandin on this. ROX-Filer should not be going out of > > its way to fix a mount flaw. > > Hmmm, that is where I was agreeing with the behavior you described below. > Don't you think it is a > security problem? What is the expected behavior for executing a JPG file? > [...] Executing a file ending in '.jpg' is the same as typing './file.jpg' on the terminal. Security problem? Assuming you're allowing terminals, then any file can always be executed (i.e., ROX cannot stop you from running a terminal), provided the user is allowed to use a filesystem mounted with '-o exec' (exec is the default for all filesystems). The effect of "executing" such a file depends on what the file actually contains. I think there is an assumption floating around here that a file's extension _necessarily_ has something to do with its contents. This is assumption is used in a lot of programs (i.e. a lot of programs require a particular extension on data files), but in general this assumption is clearly not true. For instance, I can have a shell script intended to give a list of "jpeg" files, and I might name the script 'list.jpeg'. Actually, let me replace the term "shell script" and just call it an "executable program." After all, it's not really important that I've implemented this program as a "shell script--" I might decide to go back later and re-implement it in C, for instance. Clearly, the executable is not a "jpeg" file; double-clicking it should _not_ launch a picture viewer on the file. If I want to name my program 'list.jpeg', I should be able to do that... just set the executable bit, and ROX should assume that the +x bit takes precedence over any other type-checking mechanisms. By the way, I pointed out earlier that ROX does _not_ look inside the files during directory scanning to determine its type. This means that it necessarily must use the file extension to determine its type (ROX can also use extended attributes, but I'm assuming most people aren't using those). There's nothing wrong with this--its one of the reasons ROX is fast compared with file managers like Nautilus (which scans all files for magic numbers to determine their file type). I'm just saying that in the case of file-extension vs. executable bit, the executable bit should win. If you have a picture (really, a picture this time) named "cat.jpeg" and ROX won't launch it with your favorite picture viewer because the executable bit is turned on, the _correct_ course of action is to _turn off the executable bit_ on this file. As an additional note, let me mention that the Linux kernel has a binary interface called binfmt_misc.ko that _does_ allow you to "execute" JPEG files, among others. Basically, it allows you to set a "run action" in the kernel itself, as a way to define what happens when you type "./foo.jpeg" where foo.jpeg has it's executable bit set. You can read about it in Documentation/binfmt_misc.txt. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com |
From: Keith W. <kr...@va...> - 2005-10-27 17:47:14
|
* <ke...@ha...> [27/10/2005 1251EDT]: > Keith Warno wrote: > >Correction, for clarity: It is not ignored *all the time*. :) Seems to > >be ignored for file types that shouldn't normally be executable (how > >many of you have an executable JPEG?). Honesty I think this is lame. > >If an execute bit is set, regardless of file name, it should be honored > >and I agree w/ Brandin on this. ROX-Filer should not be going out of > >its way to fix a mount flaw. >=20 > Hmmm, that is where I was agreeing with the behavior you described > below. Don't you think it is a security problem? What is the > expected behavior for executing a JPG file? This is why I've always hated basing a file's MIME type on its file name (extension). This is a Windows-ism, and as we know in Windows it leads to lots of nice security flaws (the mere fact that Windows hides extensions by default is a flaw). Granted, this type of MIME type detection is easy to do and fast -- at least faster than pulling a magic number out of the file a la /bin/file et al. If a file is named foo.jpg -- whether on *nix or *dows -- it may or may not *really* be a JPEG file. The user has the right and the ability to name any file anything that user feels like naming it. Of course, this will then break any other program (like ROX-Filer) that determines the MIME type and therefore run action by file name. The responsibility is on the user alone to pick meaningful file names so that the programs which depend on meaningful file names will be useful. As for being a security issue, if a user went to execute something that is not executable by the kernel, that user will be informed so: kw@pigpen[2]:~$ chmod 0700 exec.jpg kw@pigpen[2]:~$ ./exec.jpg=20 -bash: ./exec.jpg: cannot execute binary file I actually have an ELF binary or two with a .jpg extension. These are CGI programs that spit out dynamic JPEG data w/ mime type image/jpeg. Anyway, I'm thinking ROX-Filer should have a set of options for casual users and another set for advanced users, and among those advanced options should be to honor the 0111 bits regardless of file name, MIME type, or anything else. Not every user needs to be saved from himself. > For executable bit not set: > 1) If type has a registered handler use it perhaps one of those handlers could be "excute the file if it is executable". > 2) If type is a 'known executable type' (e.g. shellscript, python?, perl,= =20 > others?) : > a) if ignore=3Dtrue run it (e.g. do what the type says regardless of=20 > the x bit) > b) if ignore=3Dfalse go to the next step (honor the x bit) > 3) If no registered handler display message (e.g. current 'No run action= =20 > specified...') >=20 > For executable bit set: > 1) If type is a 'known executable type' run it, ignoring any handler (e.g= .=20 > if you like -x shellscripts to be opened in your editor, but +x to be=20 > executed) > 2) If type has a registered handler use it > 3) If no registered handler and not 'known executable type' (e.g jpeg)=20 > display message (e.g. current 'No run action specified...') >=20 > Q) How do we define 'known executable type'? I don't think=20 > shared-mime-info can easily make this distinction. Shouldn't there be an= =20 > attribute or a whole section in there for this? (e.g. executable/bin,=20 > executable/shellscript, etc.) Perhaps, although I'd be happy if ROX-Filer executed the thing if the underlying FS says it's executable. If course this means that ROX-Filer itself would have to have permission to execute the file. > >I didn't do anything. It's always been that way. Sorry I didn't make > >this clear in earlier posts. Granted I update my system quite often > >with new stuff. This box and the one at home are both built from the > >ground up, LFS style. >=20 > I was kidding. Ahahah. ok. Sorry, it's been a serious week and I have the sudden urge to play some quake4. :) > >shared-mime-info here is 0.16. I don't have gnome-vfs installed. >=20 > I do, but ldd and a browse through the sources indicate that Filer is not= =20 > using it. Then what is it using?! > I don't think pango, atk or cairo are likely issues here. >=20 Probably not but I threw it in there 'cause ya never know. --=20 SA Valaran Corp GPG: 0xEC705AE9 I put the sh in IT. s/^\(I\)\(T\)$/\1sh\2/ |
From: Thomas L. <ta...@ec...> - 2005-10-27 20:19:19
|
On Thu, Oct 27, 2005 at 10:17:30AM -0700, Brandin Creech wrote: [...] > By the way, I pointed out earlier that ROX does _not_ look inside the files > during directory scanning to determine its type. Actually, it does (from 2.3), but only if it doesn't get a match for the name (and there really should be an option to turn it off for certain filesystems). -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Jonatan L. <th...@ho...> - 2005-10-27 21:00:21
|
On Thu, 27 Oct 2005 21:17:10 +0100 Thomas Leonard <ta...@ec...> wrote: > On Thu, Oct 27, 2005 at 10:17:30AM -0700, Brandin Creech wrote: > [...] > > By the way, I pointed out earlier that ROX does _not_ look inside > > the files during directory scanning to determine its type. > > Actually, it does (from 2.3), but only if it doesn't get a match for > the name (and there really should be an option to turn it off for > certain filesystems). Yeah, I guess that makes it unusable on sshfs mounts for example? especially over a 56k modem link... ;) /Jonatan -=( http://kymatica.com )=- |
From: Stephen W. <st...@ke...> - 2005-10-27 17:25:04
|
Keith Warno <kr...@va...> wrote: > > Correction, for clarity: It is not ignored *all the time*. :) Seems to > be ignored for file types that shouldn't normally be executable (how > many of you have an executable JPEG?). Honesty I think this is lame. > If an execute bit is set, regardless of file name, it should be honored > and I agree w/ Brandin on this. ROX-Filer should not be going out of > its way to fix a mount flaw. I've already argued this with Thomas, see http://article.gmane.org/gmane.comp.desktop.rox.devel/7241 and the replies. -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. Strange as I seem I'm getting stranger by the minute |
From: Brandin C. <cha...@ya...> - 2005-10-27 18:02:41
|
--- Stephen Watson <st...@ke...> wrote: > Keith Warno <kr...@va...> wrote: > > > Correction, for clarity: It is not ignored *all the time*. :) Seems to > > be ignored for file types that shouldn't normally be executable (how > > many of you have an executable JPEG?). Honesty I think this is lame. > > If an execute bit is set, regardless of file name, it should be honored > > and I agree w/ Brandin on this. ROX-Filer should not be going out of > > its way to fix a mount flaw. > > I've already argued this with Thomas, see > http://article.gmane.org/gmane.comp.desktop.rox.devel/7241 and the replies. The linked thread was an interesting read. To read the replies, I had to click on the group link and then scroll to page 5 or so. Especially interesting is when the author (Thomas Leonard) claims There's no way to tell the difference between a text file on a filesystem with everything marked executable, and a shell script without the header line. (http://article.gmane.org/gmane.comp.desktop.rox.devel/7277) This is true, but I'm curious at what exactly is meant by a "filesystem with everything marked executable" and why one needs to even consider such a filesystem. Perhaps this filesystem exists when the system administrator decided it would be fun to execute chmod -R a+rwx / as root? Of course, executing this command would be quite absurd. I'm guessing that Leonard is actually talking about the broken mount options I was referring to earlier, where FAT and NTFS filesystems report all files as "executable" when they are mounted with 'umask=0000' (intended to give non-root users full access). As I mentioned, there is a simple alternative: mount -t ntfs /dev/hda1 /mnt/ntfs -o umask=0000,fmask=0111 This allows all normal users full access to the partition, without making "everything marked executable." __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com |
From: Keith W. <kr...@va...> - 2005-10-27 18:51:26
|
* <st...@ke...> [27/10/2005 1324EDT]: > Keith Warno <kr...@va...> wrote: >=20 > >=20 > > Correction, for clarity: It is not ignored *all the time*. :) Seems to > > be ignored for file types that shouldn't normally be executable (how > > many of you have an executable JPEG?). Honesty I think this is lame. > > If an execute bit is set, regardless of file name, it should be honored > > and I agree w/ Brandin on this. ROX-Filer should not be going out of > > its way to fix a mount flaw. >=20 > I've already argued this with Thomas, see > http://article.gmane.org/gmane.comp.desktop.rox.devel/7241 and the replie= s. Doh. Yeah that sheds some light on things. Was hoping some other people would chime in on this. :) --=20 SA Valaran Corp GPG: 0xEC705AE9 I put the sh in IT. s/^\(I\)\(T\)$/\1sh\2/ |
From: Ken H. <ke...@ha...> - 2005-10-27 15:25:28
|
On Oct 27, 2005, at 8:03 AM, Keith Warno wrote: > * <cha...@ya...> [27/10/2005 1048EDT]: > [...] >> >> The second line solves the problem, removing the need to have an >> "ignore_exec" option. When I have time, I will download rox-2.3.0 and >> create a patch to fix this "problem." In the meantime, I'm using 2.2.0 >> and don't see an urgent need to upgrade. > > It'd be worthwhile to see first who else has this problem. There's > obviously some set of circumstances and/or variables that create this > issue and we have yet to determine what that set is. > > I have it both at home (ppc) and work (x86) with no xattr support. I've been using a RunAction to work around it, but that is less than ideal due to the DnD limitation. I also think that we should agree on the correct behavior before starting any fixes. |
From: Brandin C. <cha...@ya...> - 2005-10-27 15:36:22
|
--- Ken Hayber <ke...@ha...> wrote: > On Oct 27, 2005, at 8:03 AM, Keith Warno wrote: > > > * <cha...@ya...> [27/10/2005 1048EDT]: > >> > >> The second line solves the problem, removing the need to have an > >> "ignore_exec" option. When I have time, I will download rox-2.3.0 and > >> create a patch to fix this "problem." In the meantime, I'm using 2.2.0 > >> and don't see an urgent need to upgrade. > > > > It'd be worthwhile to see first who else has this problem. There's > > obviously some set of circumstances and/or variables that create this > > issue and we have yet to determine what that set is. > > I've been using a RunAction to work around it, but that is less than > ideal due to the DnD limitation. > > I also think that we should agree on the correct behavior before > starting any fixes. I believe the correct behavior for me is for ROX to never ignore the executable bit. Ask yourself why there even /is/ an option to "ignore the executable bit." The reason is because many distributions ship with mount configurations that cause FAT and NTFS partitions to incorrectly report all files as executable. This is an operating system configuration problem, and ROX provided a workaround with the "display_ignore_exec" option. However, for ROX to make the workaround _mandatory_ is not correct. Really, the users of the distributions with broken mountlines should change their configuration as I demonstrated previously, by using the 'fmask=0111' option to strip off the executable bit from FAT and NTFS filesystems. __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com |