[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] RaQ3i cgi-bin files can be download
- Subject: Re: [cobalt-users] RaQ3i cgi-bin files can be download
- From: Keith Davis <cache@xxxxxxxxxx>
- Date: Sun May 6 11:30:00 2001
- Organization: Digital Odyssey Web Development
- List-id: Mailing list for users to share thoughts on Cobalt products. <cobalt-users.list.cobalt.com>
Dan Kriwitsky wrote:
> Download? Download what? Via http the script should execute.
That's true only for a browser, just one kind of http client. Many
search engines, html validators and site snatchers can suck the syntax
right off a script without executing it. It's a long time peeve with
Perl programmers who've found their scripts in public use although
they've never published them. On a CGIwrap RaQ this is avoided by giving
a script only 0700 permission, all it needs since it runs as the
siteadmin instead of as nobody.
>Any data files the script writes to should be put in a non-web accessible directory.
This is somewhat misleading advice on a RaQ, Dan. Yes, putting data
outside of the domain path will keep it safe from browsers. But, you
also have scripts running in other domains on the server to think about.
In fact, if you put the file outside the domain and then give it 0666
and think you're safe, you've actually allowed scripts in any domain on
the server to read/write the file.
Therefore, any data file should be owned by siteadmin and should at most
have only 0600 permission. Since cgi runs as the siteadmin on a CGIwrap
RaQ giving rw permission to only the siteadmin is all that's needed. A
data file owned by siteadmin and permissioned 0600 can only be read by
the siteadmin, a script in that domain, or SU. That's as safe as you can
get and it doesn't matter where the file is kept, inside the domain path
is just as safe as outside the domain path. (BTW, if a site disables
CGIwrap for the domain with htaccess then script will run as nobody and
they will have to give a data file permissions that will allow other
site's scripts to also access their data.)
There is one more point that should be considered here. Although the
ServerAdmin cannot read/write/execute/download/chmod a siteadmin owned
file with 0600 permission, the ServerAdmin can indeed delete such a
file. But, just as weird, the ServerAdmin cannot delete or enter a
directory owned by siteadmin that has 0600/0700, therefore, store the
0600 data file in a 0600/0700 directory for max protection.
keith