Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: problem with par as other user

by vkon (Deacon)
on Jun 24, 2006 at 10:59 UTC ( #557375=note: print w/ replies, xml ) Need Help??


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
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.

      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

      forgot to ask: what are those "much more than just creating self-extracting binaries", BTW? In two words...
        Think JAR.
Re^2: problem with par as other user
by dsheroh (Parson) 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.
      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.

        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.

Re^2: problem with par as other user
by vkon (Deacon) 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.

    Very same could be ported to Linux, of course, I just didn't this...

      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: 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
        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
        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://557375]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (16)
As of 2014-10-31 19:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (223 votes), past polls