Executable bit sloppiness in modules

Replies are listed 'Best First'.
Re: Executable bit sloppiness in modules by Joost (Canon) on Dec 18, 2004 at 12:47 UTC
It could be considered sloppy to have executable bits on on non-executable modeles, but some modules actually DO contain commands (to be run when you do "./Module.pm") and ofcourse, it's always possible to do `perl ModuleName.pm` and run the code anyway. I don't really see the security issue. If you run `ModuleName.pm` you usually run the same code you run when you `require ModuleName;`, and if not, it's probably for a reason. People can hide code anywere anyway (especially with CPAN modules on `make install`). "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply] [d/l] [select]
Re: Executable bit sloppiness in modules by Juerd (Abbot) on Dec 18, 2004 at 14:05 UTC
cd `pwd` Huh?	[reply]
Re^2: Executable bit sloppiness in modules by zentara (Cardinal) on Dec 18, 2004 at 19:07 UTC
Ooops...sloppiness in my "shell programming" :-) I'm not really a human, but I play one on earth. flash japh	[reply]
Re: Executable bit sloppiness in modules by revdiablo (Prior) on Dec 19, 2004 at 00:18 UTC
Since this is begging to turn into a TMTOWTDI fest, here's how I'd write that: `find ./ -type f -print0 \| xargs -0 chmod --changes a-x` [download] I think this is preferable for a few reasons: `find \| xargs` is often much faster than `find -exec`. This is because -exec forks once for each file, whereas xargs executes the command with as many arguments as will fit on one command line. It may not seem like a big deal, but the difference in speed adds up fast. The `--changes` option only prints files that actually got changed. This may be a GNU-only switch, but it's useful.	[reply] [d/l] [select]
Re: Executable bit sloppiness in modules by ysth (Canon) on Dec 19, 2004 at 05:17 UTC
I mean the file-endings are unix Try as I might, I am unable to extract any meaning from that. Can you explain what you meant?	[reply]
Re^2: Executable bit sloppiness in modules by zentara (Cardinal) on Dec 19, 2004 at 10:09 UTC
Doh! ... I meant line-endings. If that dosn't clear up what I meant, it is that I often see files coming from windows-made archives that are all mode 777. The modules I was talking about were not, and they had \n line-endings, so they must have come from a unix-type machine. Dont'read what I write ... read what I think. :-) I'm not really a human, but I play one on earth. flash japh	[reply]
Re^3: Executable bit sloppiness in modules by demerphq (Chancellor) on Dec 19, 2004 at 11:28 UTC
IME its standard practice to convert CPAN modules to unix lines endings before upload. I know that I have had to do so for all of my modules. So im not sure you can rely on the line endings as being indicitive. For instance what mode are the modules from Data::Dump::Streamer? --- demerphq	[reply]
Re^4: Executable bit sloppiness in modules by zentara (Cardinal) on Dec 19, 2004 at 11:44 UTC
Re^5: Executable bit sloppiness in modules by demerphq (Chancellor) on Dec 19, 2004 at 11:55 UTC
Re^3: Executable bit sloppiness in modules by Mutant (Priest) on Dec 20, 2004 at 13:05 UTC
A bit of a side-track from the actual issue, but it's possible to save files in windows with unix newlines (and vice verca), so this isn't really a good indication of where the files orignally came from. But to the issue at hand.. I agree, I don't think files should be executable unless they need to be. One reason this might have happened is that if you have multiple authors working on a project using CVS, and one or more of them are running Windows, you often get files that are set to 755 checked into CVS. Once in CVS, you can't (easily) change the permissions, so everytime they're checked out, you have to manually change them.	[reply]
Re^3: Executable bit sloppiness in modules by iburrell (Chaplain) on Dec 20, 2004 at 21:30 UTC
It has nothing to do with line endings. Tar archives from Windows tend to have mode 777 for all filesbecause Windows does not have standard mode bits and the archive program can't know if files are executable or not. This also happens when Windows disks are mounted on Unix. Every file is usually has mode 777 for the same reason.	[reply]
Re^4: Executable bit sloppiness in modules by zentara (Cardinal) on Dec 21, 2004 at 13:35 UTC
Re: Executable bit sloppiness in modules by Aristotle (Chancellor) on Dec 21, 2004 at 03:47 UTC
Why would commands “hidden” in other files be any more of an issue than the fact that you run a `Makefile.PL` and then a Makefile with shell commands in it on install anyway? To be sure, untidy tarballs annoy me as well, but they have no effect on security here. Makeshifts last the longest.	[reply]
Re^2: Executable bit sloppiness in modules by zentara (Cardinal) on Dec 21, 2004 at 13:46 UTC
Well you are right of course, BUT I was thinking along the lines of "sneaking in an innocent looking file" which could be executed later as part of a hidden attack. Say the module installs a file, marked executable, and innocently named like "thanks.txt". Well I didn't bother to read it ( or may have done an automatic CPAN install". Now "someone knows" that /usr/lib/Perl5..../somedir/thanks.txt" is just sitting there waiting for a another script in the "attack-plan"( which possibly needs root priviledges to run). Sure, the same thing could be done in other ways, but this is such an "obvious hole", that can be so easily prevented, that I thought I would bring it up. I'm not really a human, but I play one on earth. flash japh	[reply]
Re^3: Executable bit sloppiness in modules by Eimi Metamorphoumai (Deacon) on Dec 21, 2004 at 13:50 UTC
I don't get it. If someone has access to execute "thanks.txt", they'll already have access to run every command in it separately, so the file itself is buying them absolutely nothing. Unless it's somehow being installed suid (which would be a huge problem) or ending up in someone else's path.	[reply]
Re^4: Executable bit sloppiness in modules by zentara (Cardinal) on Dec 21, 2004 at 13:58 UTC
Re^5: Executable bit sloppiness in modules by Aristotle (Chancellor) on Dec 21, 2004 at 14:40 UTC
Re: Executable bit sloppiness in modules by gellyfish (Monsignor) on Dec 21, 2004 at 14:06 UTC
Of course a patch to ExtUtils::MakeMaker to the effect of making the `make dist` target ensure the proper mode on the distributed files would probably be the way to go. /J\	[reply] [d/l]