Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Permissions -- Script can write when invoked by Apache but not others

Status
Not open for further replies.

NewtownGuy

Technical User
Jul 27, 2007
146
US
Hello,

I'm sure this is a permissions problem, but I can't solve it.

I have a perl script in /var/ It writes a log file among other things. It can write the log file just fine when it is invoked from a web page that runs on an Apache2 server on the same machine. The log is in the same folder as the script. So the script is executable, etc, and the file can be written.

But, that same script cannot write (append) to the log file when the script is called by another script that is running on the same machine. The other script receives a socket connection to send data to the first script, rather than receiving data from the local Apache2 server. I know the two scripts can talk to one another because other functions are performed fine.

What do I need to enable the script that writes the log file to write to the log file regardless of who invokes it ?

Thank you in advance.
 
The first thing I would suggest checking is the file and directory permissions of the location that you are trying to write to. Your scripts will execute with a given user identity (UID). Does this user have write permission to the location your trying to write? You might want or need to create a group that can access that location and add this user to that group.
 
Hello Noway2,

Thank you for your reply.

I'm running Ubuntu Server 8.04.x LTS. Here are the permissions that I currently have, all of which seem to be the defaults:

drwxr-xr-x 15 root root /var
drwxr-xr-x 5 root root /var/www
drwxr-xr-x 2 root root /var/-rwxr-xr-x 1 root root /var/-rxxr-xr-x 1 root root /var/
myscript.pl opens the log file using 'open (handle, ">>filename") or die "text";' I do not get an error message on the screen when I run myscript from the console. In fact, myscript is able to write to the log file when I run it from the console. myscript also writes the log file ok when apache2 on the same machine invokes myscript.

The problem only occurs when I have apache2 on another machine invoke the script and communicate with myscript via a bash script (socket) that makes a socket connection between the two machines. That other script is in the same folder as myscript and has the same permissions as myscript, as shown above. I know the two scripts and the two machines are communicating ok because myscript does other functions correctly when it is activated by the socket connection.

How do I find out the UID for myscript.pl and/or socket, and how to I create a new group as you suggested ? Do I have to reboot the machine for the new group to take effect ?

-- NewtownGuy
 
Based on the permissions, the files are owned by root, and readable by others which is correct for security. From your description, it definitely sounds like a permissions problem. Apparently when your script runs local, it runs as root (sudo) but when it is accessed via a socket it runs as a non privileged user. This too sounds like it would be the secure default.

Re: "How do I find out the UID for myscript.pl and/or socket". That I don't know off hand. I would have to do some Google digging to try and find out.

Creating a group and adding users to it is pretty easy. You can use the group add function(s). You said your running server edition, so you don't have a GUI (it is best to not install it anyway). Note, there are TWO: addgroup and groupadd. The former is an easier to use front end to the later. The same functions apply to adduser and useradd.

To add a user to existing group you use the following function: useradd -G {group-name} username. See this link: Be careful though. You don't necessarily want to allow (or other users) to be part of the ROOT group. Instead I would create a new group and add the users necessary to it.
 
Hello Noway2,

Thank you for the link, but I still don't know how to solve the problem. A user there by the name of 'Snap' apparently asked the same question I did, but he did not get a reply.

I have a script, not a person, that needs to write to a log file. What do I have to do to set up the log file and the script to be able to do the write ? There isn't any login procedure for a user in this case, so I don't know how to apply groups and users.

-- NewtownGuy
 
I read the link to /etc/sudoers and ran 'visudo' as instructed to edit it. It doesn't work, assuming I don't have to reboot to make the changes take effect. The link talks about giving a user the ability to execute a script, but I don't have a user. "Something" connects to my machine via a socket connection, and the socket script tries to execute the script that writes a log file, among other things.

What do I do when there's no apparent user who's trying to run the script ?

-- VideoGal

 
To be honest, this is new territory for me and I am learning as I go, so please have patience with my attempts to help you.

I know from Linux philosophy two things: 1- everything is a file and 2 - everything is going to have some sort of ID and permissions associated with it.

With that concept in mind take a look at this link:
Specifically look at sections 4 and 6. I would hazard a guess that there is some PID (process ID) associated with your script and that script is going to have certain rights. The link above specifically talks about scripts, such as perl (.pl) scripts and the rights associated with them.
 
In the list of files, directories and permissions you pasted above I don't actually see the log file you are talking about?

While it's not necessarily good practice, you could chmod 666 filename.log and see if the process can then write to the log successfully. This gives anybody write access to the file. If that works fine, then it's definitely a permissions issue.

If you print debugging messages to standard output, are you able to see them anywhere when running the script using this method? If so, you can just print out the $UID internal variable (see perldoc perlvar) to determine which user the process is running under when it fails to update the log file.

Annihilannic.
 
Hello Noway2,

I appreciate your help. I'm just frustrated all to...

I reviewed linux-permissions, especially section 4. Permissions required for webserver. I changed the owner of my scripts to nobody (chown nobody /path/to/file) as it instructed, but it still won't work. With the exception of that section on web servers, all the documentation I've seen today assumes one wants human users on the same machine as the script to execute the script, and to do so without having to enter a password. But that doesn't apply here since I don't have any human users on the server. I just want the server to allow remote execution (via a socket connection) of the script as though root were logged into that machine and executing the script.

What are we missing ?

-- NewtownGuy
 
Hi Annihillannic,

Thank you for your suggestions.

I've been using 666 on /var/ It is written ok when I run the script from the keyboard, and when the script is run from the apache2 web server on the same machine. But it's not written when my socket script runs the script that does the logging -- which is the crux of the problem.

I'm a sub-novice perl programmer. I added 'open STDERR; print STDERR $UID; close STDERR;' to the script, but I get this error:

Global symbol "$UID" requires explicit package name.

I researched that comment, but am clueless as to what package name should be included in the script, which runs 'strict'. Please advise.

I added other lines to print STDERR, such as for PID, and it writes to the screen when I run the script from the console, but not when it's run any other way. Where is STDERR going and how do I see it when the script is invoked by another application or script, instead of from the console ? I can't write to the log file I'm trying to write to because, well, Catch-22...

-- NewtownGuy
 
If you are already using mode 666 then it's definitely not a permissions issue (except for the unlikely scenario that one of the parent directories is not 'executable').

Sorry, I didn't realise you need to use English; to use the "long" format of some built-in variables, so you can either do that first, or use the short format $< (see the first few paragraphs of perldoc perlvar).

You may also want to print the effective user ID, i.e. $EUID or $>. This is probably all irrelevant now anyway since you have already given the file global access.

When you open the log file, are you specifying the full path?

Can you show us the code or method by which the script is invoked?

Annihilannic.
 
PROBLEM SOLVED

I had two scripts, one receiving commands from a local apache server, and the other receiving commands from a socket script. There was a typo in the path of the log file in one of the two scripts. Sigh...

Thank you everyone for your help.

-- NewtownGuy

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top