Using perl 5.8.0, Linux 2.4.20-30.9, RedHat 9.0.
We have many .cgi's that allow privileged users to upload files to the server through a web browser. We've had these .cgi's for years and have never had any problems with them. Recently the files being uploaded are sometimes being given 600 permissions instead of 644 permissions, which they always used to be given. When you try to access the uploaded file set to 600 with a web browser you get a 403 Forbidden error. I was playing with it last night and uploaded the same file using the same .cgi about 10 times and every time it was given 600 permissions. Then, without changing anything, the next couple of times the file was uploaded with 644 permissions, then it went back to the 600 permissions. I'm really lost. Any help would be great.

after you upload the file have perl change the perms on the file.

dont rely on the umask.

but it sounds like some other process is messing around with the files.

We're working on changing the perl files to change the permissions manually. We just have so many that I was hoping there would be an easier way.

I agree it sounds like another process is screwing up the files, but I have no idea what process it would be or how to find it. If you have any insight on that I'd appreciate it. Thanks for your help.

unfortunetly i never used perl to upload files. i always use FTP.

1) when files are uploaded are they always uploaded to the same directory no matter what user signs in?

2) is there any corrolation to the user sign in to the unix account on the machine?

3) are all the users umask the same?

First, I really appreciate you helping me out with this. I've been on other forums and nobody has tried to help as much as you have.

1) The files that are being uploaded can go to hundreds of different folders. We have multiple sites using the uploading scripts, and within those sites users can choose to upload the files in various places.

2) The users on our sites have no correlation to our unix users. On the sites we're having the most problems with, there's an average of about 50 users, with all usernames defined by the user.

3) I didn't even know about umask until your last post. The only thing I know how to do with it now is type it in and get 0022 in response, which I think means all uploaded files will be given 644 permissions. I did man umask but I couldn't even figure out where to find the umask info. It listed all the bash builtins and I got confused.

We did figure out that we only have this problem at certain times. The only times we know of so far is sometime around 11:00 pm MST and between 5:00 pm - 6:00 pm MST. Between 5:00 and 6:00 it's very rare that the file gets uploaded with the correct permissions. We must have done 30 uploads in that time span and only 3 or 4 were uploaded correctly. We were running top at the same time, but we couldn't find any odd-looking processes running.

Thanks again for your help.

First, about umask... When a process creates a file, it uses the open() or creat() system calls. Both calls have a mode parameter to set the mode of the file. The mode is the number you're mentioning as 600 or 644. The kernel does not use the mode directly as it creates the file. Instead the file's mode is set to the expression "mode & ~umask". A process can change its umask value via the umask() system call. But it inherits its original umask from the parent.

This leads to my suspect: a faulty parent. The parent process, when overloaded or something, is spawning children incorrectly.

I'm not a web expert nor a perl expert. But I think that the parent of of cgi scripts is the webserver itself. The error in the parent should be researched. Maybe a new release or something is available?

If I'm right, a quick fix would be to modify the cgi scripts to set their umask to 0. This is probably as simple as inserting "umask(0)" or something like that as the first line. Maybe Optimus_P can chime in here with the perl syntax for that.

It really seems like that's the problem. We're still narrowing down any patterns, but it here's any consistency we've found so far.

Roughly 11:00 pm - consistently wrong permissions
5:00 pm - 6:00 pm - consistently wrong permissions
10:00 am - 10:30 am - not as consistent as 5-6, but still pretty bad

Maybe the parent is being hit with another process on the server at these times, and is causing it to do what you described above.

We don't have any crons running at these times. I'm using top during these times to try to find any wierd processes, but have been unsuccesfull. I'll start looking into the parent for .cgi's and see if I can find something.

Thanks.