in reply to
Re^3: problem with par as other user
in thread problem with par as other user
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.