Re: Works as root but not as user

[the.noonings]

Alan Stewart wrote:
On 23 Feb 2005 at 8:42, the.noonings wrote:
 

----- Original Message -----
From: "the.noonings" <the.noonings[at]verizon.net>
To: <par[at]perl.org>
Sent: 21 February 2005 20:27
Subject: Works as root but not as user
>>
>> Hello,
>> I have a problem running pp on Mandrake Linux as a regular user.  
Root
  

Does the problem occur when running pp, or when running the packed 
executable?

 

>> runs just fine.  In fact as root  I can chdir and run  >> 
PAR0.87/contrib/automated_pp_test/automated_pp_test.pl just fine.  No
>> automated_pp_test.pl tests run as a regular user.
>>
>> To simplify things, I created this file hello.pl
>>     #!/usr/bin/perl -w
>>      print "Hello\n";
>>
>> And then I
>>    pp -o hello hello.pl
>>   ./hello
>> And I get
>>      No such file or directory at -e line 725.
>>      BEGIN failed--compilation aborted at -e line 835.
>>
  

This looks like pp ran OK and then the executable bombed.
 

>> Again, it works fine as root.  It bombs as a regular user.  I 
don't know
>> what I am missing here.  Any help would be appreciated.
>> Thanks
>
>One suggestion: check that the environment variable USER is set.
>If not, PAR will use /tmp/par_SYSTEM for _all_ users. So, if you
>don't own this directory and are not root, tough beans.
>
>Solution: add the line "export USER=myloginname" to your .profile.
>
>I'm probably wrong, put it's one line to eliminate.
>
>
>Ivor.

I have the solution.  I thought I sent this a number of days ago.  
Sorry for the delay.  I am also here making a PAR suggestion.

I had installed PAR as root, which is of course necessary.  However,
    /tmp/par-loginname
installed with owner and group both "root", and lacked write 
permissions.  I changed group to "users" and chmod 775 
/tmp/par-loginname and now everything works fine.

Is "users" a universal enough group that PAR should automatically
   chgrp -R users /tmp/par-loginname
upon installation?  And of course
    chmod -R 775 /tmp/par-loginname
Thanks
  

I am going to guess that you have an error when running pp itself, and 
the following may be what is happening.
You login initially as some non-root user, say "nooning", and then in 
order to install PAR, you "su root", but your environment variable 
still say your user name is "nooning", so the temp dir that is created 
by parl running during the install is named something like 
"/tmp/par-nooning" but the real owner is root (755).

That dir isn't so much "installed" as left over.
Then when you exit root back to being "nooning" again and run pp, 
"/tmp/par-nooning" still exists, but pp fails for lack of rights to 
create cache dirs inside of it.

If that fits what you are seeing, then the best thing to do is not 
broaden the rights of the dir to an unpredictable group of users. Who 
knows what groups different systems have?

Either delete the temp dir after installing PAR and let it be 
re-created during pp/executable, or set PAR_GLOBAL_CLEAN=1 while you 
install PAR and it will be auto deleted.

Perhaps the installation process should automatically set 
PAR_GLOBAL_CLEAN=1 and then set it back to its former value?

Alan
 

About the previous "test" email: I signed up with Verizon DSL with a 
year's commitment.  If I click on "reply" my emails do not make it to 
par@perl.org,  I have to copy and paste to an original email.  Bummer.  
Okay, back to the subject at hand.

Alan, your description of my installation process fits 100%.
Setting PAR_GLOBAL_CLEAN=1 would clean out the /tmp/par-nooning 
directory, but leave it with the original root owner and group.  Right?

Besides the solution of being (real id) root when installing PAR/pp, how 
about having par automatically reassign real ID instead of effective ID 
to the owner and group before exiting the process.  Here is something 
that worked
on Linux Mandrake.  The Solaris code below is from some very old notes.  
The rest I just tested.

------------------------paste
# Use getlogin and getpwuid to get the real uid.  On Linux Mandrake,
# using Perl 5.8.6, the symbols $>, $<, $) and $( all report the
# effective, not the real uid and gid.
# On Sun machines there might be a problem with getlogin
# returning a miximum of only 8 letters.  We need to use
# "who am i" instead.  We cannot use "who am i" for all unixes
# because old notes tell me that "who am i" and "who am I"
# are inconsistent across OS platforms, and I don't know the
# rules for each.
# The problem at hand is not an issue on Windows (I hope)
if ($os =~ /SunOS/i) {
  chomp($username = `who am I`);
  $username =~ m/(\w+).*/;
  $username = $1;
} else {
  # Other unix type
  # getlogin reads from utmp, getpwuid from /etc/passwd
  $username = getlogin() || (getpwuid($<))[0];
  chomp($username);
}
chown -R $username /tmp/par-nooning
$group number = getgrnam($username); # Would this work on Solaris?  BSD?
chgrp -R $group_number /tmp/par-nooing
-----------------------------------------end paste