Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer's security. If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.

I'm guessing that these scripts are CGI scripts. The user 'nobody' is the user that the web server is running under. It's a real user, but generally it has very minimal rights to read other user's files or write to other user's directories.

What are the permissions of these files? It should be simple to set them so that no other users can access them.

Perl Training in the UK <http://www.iterative-software.com>

<reference type="comedy" act="Abbot and Costello">I thought he was playing centerfield ... </reference> =)

Actually, there is a user called 'nobody', in the sense that there's an entry for such in /etc/passwd on your system (I assume you're running some *nix-like OS). It's there to provide an unprivileged userID for daemons (like webservers) to run under. If you set the permissions on the files and group membership of nobody appropriately, you shouldn't have a problem.

I imagine that you're talking about CGI scripts? Another possibility is that the script is owned by nobody and set to run with the permissions of that user. If you feel like you MUST give ownership of the files it creates to other people, you have a couple options:

• run the scripts under a regular user's name (suEXEC does this w/Apache, or unset the setuid bit)
• have a cron job (running with root's privileges) change ownership of the files periodically

I'd prefer to do the second anyway, as it's pretty easy to add other maintenance (e.g. backup) functions to the cron job; also, if you don't already have the suEXEC like mechanism in place already it's just easier to implement.

HTH!

perl -e 'print "How sweet does a rose smell? "; chomp ($n = <STDIN>); 
+$rose = "smells sweet to degree $n"; *other_name = *rose; print "$oth
+er_name\n"'
[download]

Examine the permissions on the files themselves, and on the directories; compare those to the users and groups that will try to access those files. That will tell you who can do what.

Although nobody is a valid user on most Unix systems, it is considered bad practice for that user to own any files on the system. See this thread and this response to an attempt to set files to be owned by nobody.

chmod +s my_program_name.pl
[download]

chown my_user_name my_program_name.pl
[download]

($<,$>)=($>,$<);   # Swap effective and actual user ID
open(FILE, ">>/tmp/myfile") or die "Can't open /tmp/myfile";
print FILE "stuff";
close(FILE);
($>,$<)=($<,$>);   # Swap effective and actual user ID
[download]

Suid programs are usually not used because of security reasons. You should learn about the perl concept of 'taint' in order to get started on learning about cgi security.

Update: fixed a few typos

It should work perfectly the first time! - toma

You could ask an admin to have the NFS fileserver allow root on your machine to root access to the file system. (Probably not a good idea security wise and some admins will wail loudly if you ask for this.) Another option would be to run as anybody but root. If this isn't an option, you could "set uid" (see perlvar) or just write your files to a local filesystem.

-- bluto

CGI-Wrap runs your CGI programs as you (and creates files with you as the owner). This cuts down on the ability of other system users to tamper with your files in a web server environment.

Richard-oakbox

"If what I'm saying doesn't make sense, that's because sense cannot be made, it's something that must be sensed"-J.S. Hall