Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I have a script that runs as a small database, reading and writing to several flat files over the course of the script. It will generate the files if not already there, and (on my system at least), these files are 'owned' by nobody - that's literally the name assigned. I'm concerned because since no one owns the files, anyone can delete or alter them. Would chmod-ing the files over the course of the program be the answer, or is there a way to have the files generated under my name, since the script runs under my name as well? Please forgive my ignorance, I know not what I'm doing =)

Replies are listed 'Best First'.
Re: File Protections
by tadman (Prior) on Jun 28, 2001 at 18:13 UTC
    'nobody', despite the odd sounding name, is a fully fledged regular user that lives in /etc/passwd like everyone else. Some systems have the Web server set to use a different user, such as 'www', but the principle is the same. Any files you create from a script running under a Web server are "owned" by the user the Web server is running as. On a typical system, this is 'nobody'. You might think that since you own the scripts they run as you, but this is not normally the case.

    Since they are owned by a user, they can't be changed or altered by anyone but that user, or the admin, of course, unless you've granted other permissions. Be aware, though, that other script programs on the same server may be able to access and modify these files, even if these scripts aren't yours.

    If you want to run the scripts as a real user, and not this 'nobody' account, you have to tell your Web server to do this explicitly. It is a bit more work to do since the Web server will have to do some special stuff to get your particular account activated for the purpose of running the script, but it is more secure.

    Apache has a method called suEXEC which handles this. Setting it up properly can be a bit tricky, so be careful. From the documentation:
    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.
Re: File Protections
by davorg (Chancellor) on Jun 28, 2001 at 18:07 UTC

    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.

    --
    <http://www.dave.org.uk>

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

Re: File Protections
by arturo (Vicar) on Jun 28, 2001 at 18:19 UTC

    <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"'
Re: File Protections
by clintp (Curate) on Jun 28, 2001 at 18:09 UTC
    The user "nobody" is a perfectly valid user name, and has all of the rights that any other user has. It's just a default "safe" user that some software uses.

    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.

Re: File Protections
by toma (Vicar) on Jun 28, 2001 at 20:26 UTC
    If you change the permissions on the cgi program with
    chmod +s my_program_name.pl
    and you are the owner, which you can set with
    chown my_user_name my_program_name.pl
    and then you add this sort of thing to the cgi where you work with the file:
    ($<,$>)=($>,$<); # 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
    it will write the file with your user id, swapping back and forth between the 'nobody' user id and your user id.

    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

Re: File Protections
by bluto (Curate) on Jun 28, 2001 at 19:59 UTC
    I suppose that you could be running as root and writing files to an NFS mounted filesystem. If your machine doesn't have root access to the remote filesystem you will be treated as a "nobody".

    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

Re: File Protections
by oakbox (Chaplain) on Jun 29, 2001 at 17:12 UTC
    I guess my first question would be, "Who, specifically, are you worried about tampering with your files?" I program for a web site. My site sits on a server with 5 other virtual web sites. (Apache) My concern is that an admin of one of these other sites might write a script that would manipulate my data files. To isolate the virtual sites from each other, I am running CGI-Wrap on my system.

    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