Hiya,

We've got ourselves a Linux / Apache / MySQL / PHP app that needds to
do such things as write out log files. I thought it would be "neater"
to have these files come out as owned by apache:apache, rather than
nobody:-1 which is how it was coming out with the default Apache (2.0)
configuration.

Is there a security risk in changing the user and group in httpd.conf to
both being apache?

Or am I better off leaving it as "nobody" and then setting permissions
as needed?

In fact I seem to be having trouble writing out even when the
directory I'm writing to is chmodded 666... or owned by the apache
user.

I can write to /tmp/test and I get the test file, owned by apache.
But I write to /var/opt/our_system/logs/test and it doesn't come out.

/var/opt/our_system/logs/ is owned apache:apache and is chmod 644.

Thoughts please? Pointers to idiot tutorials???

--
Ne magna voce clametis ne canatis. Ne sine mediocritate edatis neve
bibatis. Ne ructetis. Ne inflationibus ventris alicui noceatis.
Ne consuetudinem vomitandi conservetis. Ne sitis satyri.

Mary Pegg wrote:

Not as long as you properly setup the apache group and user.

Only if the user and group is not properly setup.

Whatever suits your needs.

How did you do this, did you su to apache and write the file?


--
No exceptions. Complying with protocol is not a choice, it is a
discipline.

Baho Utot wrote:

So, what is "peroperly set up"?

[snip file writing problem]

No, it was from within the application, but i changed the directory
permissions to 755 and it worked fine.

--
Ne magna voce clametis ne canatis. Ne sine mediocritate edatis neve
bibatis. Ne ructetis. Ne inflationibus ventris alicui noceatis.
Ne consuetudinem vomitandi conservetis. Ne sitis satyri.

Mary Pegg wrote:

No shell access for starters. You don't want users to be able to login as
the apache user.

That's why you did not find the error. su to the account/user then try to
create the file. If it works when you su to the account/user it will work
when apache starts logging data.

You should change the perms to 660 or 600 if all you are doing data logging.
Ordinary users should have no access to the log file.

--
No exceptions. Complying with protocol is not a choice, it is a
discipline.

Baho Utot wrote:

Okay, anything else? We don't have "users" on this machine, only two
of us sysadmins.

Bear with me here - I've been using Linux for years but I still find
permissions a headache. I found that I needed to set the "x" bit for
Apache to write to the file, even though Apache owned the file and
the directory it was in.

Mary Pegg wrote:

Everything in the passwd file can be considered a user or account, user here
doesn't mean a physical entity.


The x perm on a directory allows access to that user/group. Is that what
you mean? I was refering to the perms on the log file itself.

Baho Utot wrote:

Err, yes, but when you said "you don't want users to be able to login
as the apache user" it looked very like you were referring to actual
human users. One does not, after all, generally refer to processes
or daemons or what-have-you "logging in".

For Apache to write to the logfile I'm using, the x perm on the directory
needs to be set. If I "su - apache" and try to read or write to the file
myself, I do *not* need the x perm to be set.

This does not bear out what you said above.

--
Ne magna voce clametis ne canatis. Ne sine mediocritate edatis neve
bibatis. Ne ructetis. Ne inflationibus ventris alicui noceatis.
Ne consuetudinem vomitandi conservetis. Ne sitis satyri.

"Mary Pegg" <nospam@widetrouser.freeserve.co.uk> wrote in message
news:TgvVb.1647$vo1.865@newsfep4-winn.server.ntli.net...
A service, such as apache, runs as a user (usually, but not always as the
user 'nobody') If you check your logs after you restart apache you will see
where apache 'logged in'

Logging in is when the user identifys themselves to the service and is
permited to use that service based on their login details.

Mary Pegg wrote:

[snip]

Then something else is wrong, when to su to the user apache you are using
the same perms as apache would when it is running. Perhaps the entries in
http.conf are needing correction.