Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

As part of an installation procedure of a piece of software, I use:

curl -s <url-to-targz> | tar -p -x -z -C /

inside a Perl script (I use qx($command) or system($command), either will do.All goes well, and the tar ball is installed to the / of my system, but when I do the same thing to an nfs share:

curl -s <url-to-targz> | tar -p -x -z -C /my-nfs/opt

Then the following occurs:

  • When I do this on the prompt, this goes well (i.e. all my permissions that I saved in the tar ball are still in place).
  • When I do this from withing the Perl script (or a shell script, for that matter), either qx($command) or system($command) leaves me in with the situation that the permissions are changed (for example, what was executable, is no longer executable).

I am suspecting this has to do with umask (which is 022 on my system), and normally the -p flag should take care of that, but still no joy in this case. Does anyone have any suggestions for me (other than read the manpage :-))?

I have also tried something like system("umask xyz; $command"), but (probably because the $command is using a fork of my process, which gets the umask 022): also no joy.

Edit: Some of the answers indicate I should use umask of Perl. I think a umask 000 will do the trick (but I will see this in the morning, when I am at the system. umask though, has a different effect on files and directories. Is there a way to disable umask entirely during the run of my progran (despite a thousand security reasons against it).

share|improve this question
    
When you run this command on the prompt, are you root? I think tar -p also saves the owner (I'm really not sure, the man is vague), which won't work as normal user. Perhaps that's a problem?! –  mpy Jun 8 '13 at 16:14
    
Indeed, I run it as root. When running as normal user, -p does not restore permissions in the right fashion. As root, it should. Also, there is user:group information safed in the tar ball, which you can't restore when running tar as non-root –  Willem Jun 8 '13 at 17:05
    
And it's working as root also on the NFS mount? I suspected that the error is due to the fact that lots of nfsd are configures to map root to nobody (option rootsquash). –  mpy Jun 8 '13 at 17:52
    
I belive there's a perl function to change the program umask. Or, perhaps "umask xyz && $command" would work. –  jpaugh Jun 8 '13 at 18:20
    
@jpaugh: Thanks I will try that. –  Willem Jun 9 '13 at 21:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.