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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

Davide Bianchi <davideyeahsure@onlyforfun.net> wrote in message news:<c1i5tl$1iba6h$3@ID-18
487.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.

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]