Unix administration - File ownership - root vs. ???

This is Interesting: Free IT Magazines  
Home > Archive > Unix administration > March 2004 > File ownership - root vs. ???





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author File ownership - root vs. ???
bad_knee

2004-02-25, 9:39 am

Hello All,

I admin about 12 unix boxes where I work, all running Solaris 9. One
of them is a web server for our intrAnet and it runs apache. The other
day, I was sshd into the web server and noticed all the files and
directories under cgi-bin were owned by httpd:httpd and most had write
perms to them. Yes, the webserver is running as httpd. I thought
someone had rooted the box at first. Anyway, as it turns out, the
boss wanted to be able to access the web server files over nfs from
his linux box in his office, so he set all the perms to something that
worked for him. He said he did not want the files owned by root for
security reasons.

I wasn't expecting an clear answer from him at this point, so I
thought I would toss the question up here. Why would root ownership
on a file (excluding setuid binaries) be a bad idea from a security
standpoint?

I'm asking because the convention I use is chown root:root 644 for
most things. If I need write access to the file by a regular user, I
would root:user 664, or user:user 664. If what my boss said holds any
water, I need to rethink my ideas on file ownership strategy, so this
is why I pose the question.

Thanks,
bl8n8r
Davide Bianchi

2004-02-25, 9:39 am

bad_knee <bl8n8r@yahoo.com> wrote:
> thought I would toss the question up here. Why would root ownership
> on a file (excluding setuid binaries) be a bad idea from a security
> standpoint?


Because you need to be root to edit those files, so you are going to
use root when isn't really necessary.

Davide

--
| Well, my terminal's locked up, and I ain't got any Mail, And I can't
| recall the last time that my program didn't fail; I've got stacks in
| my structs, I've got arrays in my queues, I've got the : Segmentation
| violation -- Core dumped blues. If you think that it's nice that you
Casper H.S. Dik

2004-02-25, 8:33 pm

Davide Bianchi <davideyeahsure@onlyforfun.net> writes:

>Because you need to be root to edit those files, so you are going to
>use root when isn't really necessary.



But the files being owned by the same uid as the web server run with
is the other wrong choice.

Casper
bad_knee

2004-02-25, 9:33 pm

Davide Bianchi <davideyeahsure@onlyforfun.net> wrote in message news:<c1i5tl$1iba6h$3@ID-18487.news.uni-berlin.de>...
> bad_knee <bl8n8r@yahoo.com> wrote:
>
> Because you need to be root to edit those files, so you are going to
> use root when isn't really necessary.
>
> Davide


Makes sense. Thanks for the reply Davide.
TCS

2004-03-02, 7:35 pm

On 25 Feb 2004 04:50:02 -0800, bad_knee <bl8n8r@yahoo.com> wrote:
>Hello All,


>I admin about 12 unix boxes where I work, all running Solaris 9. One
>of them is a web server for our intrAnet and it runs apache. The other
>day, I was sshd into the web server and noticed all the files and
>directories under cgi-bin were owned by httpd:httpd and most had write
>perms to them. Yes, the webserver is running as httpd. I thought
>someone had rooted the box at first. Anyway, as it turns out, the
>boss wanted to be able to access the web server files over nfs from
>his linux box in his office, so he set all the perms to something that
>worked for him. He said he did not want the files owned by root for
>security reasons.


>I wasn't expecting an clear answer from him at this point, so I
>thought I would toss the question up here. Why would root ownership
>on a file (excluding setuid binaries) be a bad idea from a security
>standpoint?


It is a bad idea because only the root can read them meaning that some
process must run as root that otherwise could run as a user.
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com