Re: problem with par as other user

in reply to problem with par as other user

because of this /tmp par behaviour, I switched off from it
Just think what a security hole it is!

I even developed my own solution which unpacks in-memory on the fly, but other alternatives (including commercial ones) will suit better for you.

just don't be stuck with a solution that is simple and wrong!
:)

Comment on Re: problem with par as other user

Replies are listed 'Best First'.
Re^2: problem with par as other user by tsee (Curate) on Jun 24, 2006 at 14:12 UTC
You are welcome to chime in on par@perl.org and help fix it. We are all just a bunch of hard-working volunteers. Personally, I put a couple of hours a week forward to fix bugs in PAR and clean up the RT bug queue. On an aside: The module can do much more than just creating self-extracting binaries. Doing all which PAR does in-memory is probably not possible to realize.	[reply]
Re^3: problem with par as other user by vkon (Curate) on Jun 24, 2006 at 14:47 UTC
thanks, I'll subscribe this list. However unzipping to /tmp seems to me too simplistic. BTW Tcl/Tk's way of packaging (starkit and similar stuff) looks better BR vkon	[reply]
Re^3: problem with par as other user by vkon (Curate) on Jun 24, 2006 at 14:58 UTC
forgot to ask: what are those "much more than just creating self-extracting binaries", BTW? In two words...	[reply]
Re^4: problem with par as other user by tsee (Curate) on Jun 24, 2006 at 15:06 UTC
Think JAR.	[reply]
Re^5: problem with par as other user by vkon (Curate) on Jun 24, 2006 at 15:13 UTC
Re^2: problem with par as other user by dsheroh (Monsignor) on Jun 24, 2006 at 14:48 UTC
Would you care to elaborate on the "security hole" aspect? Provided that you have a *nix system configured with this sort of thing in mind (e.g. permissions 1777 (rwxrwxrwt) for /tmp), /tmp can be set to permit any user to create and write to their own files there without allowing them to modify or delete anyone else's.	[reply]
Re^3: problem with par as other user by vkon (Curate) on Jun 24, 2006 at 15:10 UTC
first, you're not always on nix. I mean middle-weighted Joe user not always on nix, especially when it is not developer but namely user. (PAR isn't nix-only, isn't it?) But even on nix, root user can still modify poor Joe's scripts. This probability is low, but it equals zero with in-memory unpacks. Windows users are 99,99% work under administrative privilegies, so replacing /tmp files will be easy for them. Yet, /tmp space could be full. Don't tell me that entire system will be badly functioning in this case. Par will not be working in this case, but other programs will... Other security risk - is that PAR reuses same /tmp between runs,and this, IMO, could also be busted. Addition: - another one, when PAR remains its files in /tmp after finishing the program, this means the more program I'll run the larger /tmp will be, and I dislike this.	[reply]
Re^4: problem with par as other user by tsee (Curate) on Jun 25, 2006 at 13:28 UTC
Okay, I need to address this eventhough I think we are getting somewhat off-topic now. Your points aren't totally off. You are right: PAR runs on nix, Windows and Mac OS X at the very least. The root user being able to modify other users' files is a feature, not a bug. The root user can replace /usr/bin/perl with /home/malicioususer/bin/rootkit anyway! So if your root account has been compromised, talking about the security risk of replacing files in /tmp/ is absolutely* pointless. The comparison to in-memory unpacks isn't helpful either since the original executable (and any signatures thereof) could have been modified by the root user. Windows users having admin priviledges is a bug in Windows + a bad decision of the system administrator. Now, to be honest, you describe the real world situation well. What you miss, though, is that the same point I made above about replacing the executable applies as well. If you control the executable, replacing its contents after unpacking is much harder than doing it up front. The --clean option makes sure that the cache area is cleaned after each run. PAR honours an environment variable to set alternative cache paths. So if you dislike /tmp because a) it might be full (which it should not be!) or b) you want to use a "secure" user path, you can do that. Other programs might work or might not if /tmp is full depending on whether they use temporary data on disk or not. Furthermore, if only in-memory unpacking is possible, packaging some libraries that do their own dependency checking using the file system would not be possible. A hybrid solution, however, would be even more complicated than PAR is already.	[reply]
Re^5: problem with par as other user by vkon (Curate) on Jun 25, 2006 at 17:37 UTC
Re^5: problem with par as other user by rvosa (Curate) on Jun 27, 2006 at 00:08 UTC
Re^6: problem with par as other user by tsee (Curate) on Jun 27, 2006 at 11:48 UTC
Re^2: problem with par as other user by vkon (Curate) on Jun 29, 2006 at 06:55 UTC
PS. I am replying to Ace128 who asked quite essential question, so it do not fit in CB. But this could be useful in general, I hope. explanation on how redistributable perl is done with only in-memory unpacks First of all, previous (lost, but easily recoverable) archive previously located at http://www.vkonovalov.ru/perl-for-cd.zip was perl-5.6.1 + perl/Tk Currently I placed newer at http://www.vkonovalov.ru/files-exchange/perl58tk84-for-cd.zip which is based on perl-5.8.? and Tk GUI with Tcl/Tk, which is better than perl/Tk. (looks similar but more powerful) How that works. start.exe is a tiny C program (explain later) which uses perl58.dll and searches for file './modules/modules.pm' and feeds it to perl interpreter. This bootstraps in such a way that required modules are unzipped and loaded so 'modules/perl58.zip' becomes available to @INC. Unlike PAR, perl58.zip is not unzipped entirely, only used what is used. Also, just not using filesystem at all could be beneficial in some cases. How can I make file set even smaller If I'll go further this easy way, (which probably was the way of all commercial packers), then: incorporate files "modules/modules.pm", "modules/redo.pm" into mentioned small C program, as C string, and eval it later. "start.pl" could be placed inside "perllib.zip" Use famous technique on appending "perllib.zip" to executable, which is perfectly possible. All required extensions could be built into perl58.dll, now this possible, see http://perldoc.perl.org/perl588delta.html#Installation-and-Configuration-Improvements. This requires compilation of perl, (but I'll better place required DLLs near around) So this ends in 2 files: 1 EXE + 1 DLL, including Tcl/Tk. start.exe, a tiny C program Its trivial. It loads perl58.dll, calls RunPerl. Dead simple. The only trick used (and its not my invention of course) it checks its name to have an idea on what script to run. So I compiled the stub once, and then I just copy with different name to make engine to start "name.pl" script. Same as busybox. Read more... (3 kB) Very same could be ported to Linux, of course, I just didn't this...	[reply] [d/l]
Re^3: problem with par as other user by Ace128 (Hermit) on Jun 29, 2006 at 12:20 UTC
Hey! Well, since this may be of more interest to more, I ask it here. What do I have to do minimum to get this start.c to compile properly? I've downloaded the source from Activestate and setup Dev-C++ to find the headers and libs. Now, when I compile I get this: Read more... (5 kB) I was hoping I wouldn't have to install M$ Visual Studio X. It seems that I have to do "configure" (to create the config.h file that is missing), but how to do this in windows? Would be damn cool if I could compile this start.c, since this little project seems really cool to me :) And besides, I need to add a pause in there to make it pause, and not close the terminal window when some tk script Im runing doesnt work. :) I get some error, but the window closes and I cant see the error. (Probably some module missing in this package that I use). Oh, and maybe somehow to get rid of the terminal window aswell when the tk script actually works! But, I suppose the Perl interpreter is boundled into this start.c, and thus I need to be able to compile the whole Perl source aswell? Thanks, Ace	[reply] [d/l]
Re^4: problem with par as other user by vkon (Curate) on Jun 29, 2006 at 14:37 UTC
why you need to compile start.c, in the first place? Regarding compiling perl shipped with activestate with mingv, or free MS compiler, or else - please seek monastery, I remember many articles here. Regarding `C:/perl-5.8.8/perl.h:37:23: config.h: No such file or directory` [download] You do not have to create config.h with configure. Config.h shipped with Perl and is inside its directory ./lib/CORE/*.h To get rid of terminal window - thats easy. Also, it should not show in the package that I've sent. On which step do you see them? Did you succeeded running perl-cd-blablabla, BTW?? BR, Vadim.	[reply] [d/l]
Re^5: problem with par as other user by Ace128 (Hermit) on Jun 29, 2006 at 19:04 UTC
Re^6: problem with par as other user by vkon (Curate) on Jun 29, 2006 at 22:16 UTC
Some notes below your chosen depth have not been shown here
Re^6: problem with par as other user by vkon (Curate) on Jun 29, 2006 at 22:14 UTC
Some notes below your chosen depth have not been shown here

In Section Seekers of Perl Wisdom

explanation on how redistributable perl is done with only in-memory unpacks

How that works.

How can I make file set even smaller

start.exe, a tiny C program