File permissions for a wiki-like site

[Adam Baker]

Hello,
I'm writing a site where a handful of people will be able to edit
the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)

Thanks,
Adam

[Jerry Stuckle]

Adam Baker wrote:

Hello,
I'm writing a site where a handful of people will be able to edit
the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)

Thanks,
Adam

The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's completely
between Apache and the user.

And beware that unless you implement your own security, any of those
people will be able to edit any of the files.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Adam Baker]

On Sep 14, 5:06 am, Jerry Stuckle <[e-mail]:

Adam Baker wrote:

Hello,
I'm writing a site where a handful of people will be able to edit
the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)

Thanks,
Adam

The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's completely
between Apache and the user.

And beware that unless you implement your own security, any of those
people will be able to edit any of the files.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?

It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?

Thanks,
Adam

[Jerry Stuckle]

Adam Baker wrote:

On Sep 14, 5:06 am, Jerry Stuckle <[e-mail]:

>Adam Baker wrote:

>>Hello,
I'm writing a site where a handful of people will be able to edit
the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)
Thanks,
Adam

The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's completely
between Apache and the user.

And beware that unless you implement your own security, any of those
people will be able to edit any of the files.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?

It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?

Thanks,
Adam

Every process in the machine runs under a specific user. That's what
determines the permissions available to the process.

No one "owns" Apache. There is a user (or even more than one) which
owns the files Apache uses to run. And there is a user for the Apache
process. They may or may not be the same.

And chmod to 777 is highly dangerous - it allows anyone on your server
to read and write to your files. It should never be done if you value
those files, IMHO.

Rather, you should set up the users and groups to provide the
appropriate permissions, then set the file permissions accordingly.

I'd suggest you get a book on Linux Administration. It will help you
with a lot of different things. And I'm not being sarcastic about the
suggestion; learning some of the basics of Linux administration will
help you understand a lot of this better - it can be quite confusing.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[The Natural Philosopher]

Jerry Stuckle wrote:

Adam Baker wrote:

>On Sep 14, 5:06 am, Jerry Stuckle <[e-mail]:

>>Adam Baker wrote:
Hello,
I'm writing a site where a handful of people will be able to edit
the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)
Thanks,
Adam
The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's completely
between Apache and the user.

And beware that unless you implement your own security, any of those
people will be able to edit any of the files.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?

It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?

Thanks,
Adam

Every process in the machine runs under a specific user. That's what
determines the permissions available to the process.

No one "owns" Apache.

Well actually someone DOES. Even if its a dumnmy user like 'www-user' or
somesuch.

Unless you are dumb enough to run apache as root..and even then root
'owns it'

A quick trawl through the PS command if you are oin unix, will show waht
it runs as user wise.

Viz n a system here
~$ ps -eadf | grep apache
root 9197 1 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 9208 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 9209 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 9210 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 9213 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 9214 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 9787 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 11958 9197 0 Sep17 ? 00:00:00 /usr/sbin/apache2 -k start

www-data is the user who 'owns' apache and that 'user' must have read
access to any file apache wants to deliver.
There is a user (or even more than one) which

owns the files Apache uses to run. And there is a user for the Apache
process. They may or may not be the same.

And chmod to 777 is highly dangerous - it allows anyone on your server
to read and write to your files. It should never be done if you value
those files, IMHO.

Rather, you should set up the users and groups to provide the
appropriate permissions, then set the file permissions accordingly.

755 permissions are safe enough. Full read access and only user write
access.

I'd suggest you get a book on Linux Administration. It will help you
with a lot of different things. And I'm not being sarcastic about the
suggestion; learning some of the basics of Linux administration will
help you understand a lot of this better - it can be quite confusing.

[Jerry Stuckle]

The Natural Philosopher wrote:

Jerry Stuckle wrote:

>Adam Baker wrote:

>>On Sep 14, 5:06 am, Jerry Stuckle <[e-mail]:
Adam Baker wrote:
Hello,
I'm writing a site where a handful of people will be able to edit
the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)
Thanks,
Adam
The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's completely
between Apache and the user.

And beware that unless you implement your own security, any of those
people will be able to edit any of the files.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?

It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?

Thanks,
Adam

Every process in the machine runs under a specific user. That's what
determines the permissions available to the process.

No one "owns" Apache.

Well actually someone DOES. Even if its a dumnmy user like 'www-user' or
somesuch.

No, someone owns the Apache Process. You could have 10 different Apache
Processes running, each "owned" by a different user.

Unless you are dumb enough to run apache as root..and even then root
'owns it'

A quick trawl through the PS command if you are oin unix, will show waht
it runs as user wise.

Viz n a system here
~$ ps -eadf | grep apache
root 9197 1 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 9208 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 9209 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 9210 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 9213 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 9214 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 9787 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 11958 9197 0 Sep17 ? 00:00:00 /usr/sbin/apache2 -k start

www-data is the user who 'owns' apache and that 'user' must have read
access to any file apache wants to deliver.

And you are looking at the Process.

>
There is a user (or even more than one) which

>owns the files Apache uses to run. And there is a user for the Apache
process. They may or may not be the same.

And chmod to 777 is highly dangerous - it allows anyone on your server
to read and write to your files. It should never be done if you value
those files, IMHO.

Rather, you should set up the users and groups to provide the
appropriate permissions, then set the file permissions accordingly.

755 permissions are safe enough. Full read access and only user write
access.

Not at all. Would you want someone else to have access to your PHP code
or private files? Say someone who signed onto the machine with SSH or
(shudder) telnet? 755 gives them those rights.

>I'd suggest you get a book on Linux Administration. It will help you
with a lot of different things. And I'm not being sarcastic about the
suggestion; learning some of the basics of Linux administration will
help you understand a lot of this better - it can be quite confusing.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Adam Baker]

On Sep 18, 9:49 am, Jerry Stuckle <[e-mail]:

Adam Baker wrote:

On Sep 14, 5:06 am, Jerry Stuckle <[e-mail]:

Adam Baker wrote:
Hello,
I'm writing a site where a handful of people will be able to edit
the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)
Thanks,
Adam
The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's completely
between Apache and the user.

And beware that unless you implement your own security, any of those
people will be able to edit any of the files.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?

It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?

Thanks,
Adam

Every process in the machine runs under a specific user. That's what
determines the permissions available to the process.

No one "owns" Apache. There is a user (or even more than one) which
owns the files Apache uses to run. And there is a user for the Apache
process. They may or may not be the same.

And chmod to 777 is highly dangerous - it allows anyone on your server
to read and write to your files. It should never be done if you value
those files, IMHO.

Rather, you should set up the users and groups to provide the
appropriate permissions, then set the file permissions accordingly.

I'd suggest you get a book on Linux Administration. It will help you
with a lot of different things. And I'm not being sarcastic about the
suggestion; learning some of the basics of Linux administration will
help you understand a lot of this better - it can be quite confusing.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Is there a good Linux book you could recommend? I don't think I've
ever read anything about Linux that didn't presuppose a LOT of
background knowledge.

Thanks,
Adam

[Gordon Burditt]

I'm writing a site where a handful of people will be able to edit

the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)

Thanks,
Adam

The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's completely
between Apache and the user.

And beware that unless you implement your own security, any of those
people will be able to edit any of the files.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?

Often it's both.

In a typical PHP application, there are 3 different types of users:

OS users, stored in /etc/passwd.
Database users, perhaps stored in the mysql.user table. Usually a web
application "owns" a database user and uses it on its own behalf,
rather than handing out database users to people who register.
Web users, perhaps stored in some other database table, a text file,
or hardcoded somewhere. The web user is used for things like
identifying posts, and determining who gets to access what private
information.

When a user registers for your web application, you typically give them
a web user and NOT an OS user.

Files are owned by OS users. Anything Apache and PHP can write on
can be written on regardless of the Web user. If you have rules
about what Web user can write on what other Web user's stuff, you
have to write code to enforce it. Web users normally don't have
corresponding OS users.

If you are on a shared host, you may be able to FTP content in using
YOUR OS user but PHP runs as Apache's OS user. The only way to let
both write in the same place is to use mode 777 on directories (unless
they are in a common group, which they usually aren't).

>It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?

Standard UNIX file permissions don't allow a file to have two owners.

You don't normally want to give x permission to any *file* that a
web application can write on (as distinguished from *directory*,
which needs x permission). x permission is for executables and
shell scripts.

[The Natural Philosopher]

Jerry Stuckle wrote:

The Natural Philosopher wrote:

>Jerry Stuckle wrote:

>>Adam Baker wrote:
On Sep 14, 5:06 am, Jerry Stuckle <[e-mail]:
Adam Baker wrote:
>Hello,
> I'm writing a site where a handful of people will be able to
>edit
>the content using PHP scripts (FCKeditor). The content is stored as
>individual files in a directory. I'd like to validate the "editors"
>using PHP, cookies, etc.
> The question is what file permissions I need to allow for the
>content to be writable by my PHP script. Do I really need to give
>write permissions to the "other" group. Are all wikis really that
>vulnerable? (yes, I know that's the point, but for restricted wikis,
>for instance...)
>Thanks,
>Adam
The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's
completely
between Apache and the user.
>
And beware that unless you implement your own security, any of those
people will be able to edit any of the files.
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?

It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?

Thanks,
Adam
Every process in the machine runs under a specific user. That's what
determines the permissions available to the process.

No one "owns" Apache.

Well actually someone DOES. Even if its a dumnmy user like 'www-user'
or somesuch.

No, someone owns the Apache Process. You could have 10 different Apache
Processes running, each "owned" by a different user.

>Unless you are dumb enough to run apache as root..and even then root
'owns it'

A quick trawl through the PS command if you are oin unix, will show
waht it runs as user wise.

Viz n a system here
~$ ps -eadf | grep apache
root 9197 1 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 9208 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 9209 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 9210 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 9213 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 9214 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 9787 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 11958 9197 0 Sep17 ? 00:00:00 /usr/sbin/apache2 -k
start

www-data is the user who 'owns' apache and that 'user' must have read
access to any file apache wants to deliver.

And you are looking at the Process.

>>
There is a user (or even more than one) which

>>owns the files Apache uses to run. And there is a user for the
Apache process. They may or may not be the same.

And chmod to 777 is highly dangerous - it allows anyone on your
server to read and write to your files. It should never be done if
you value those files, IMHO.

Rather, you should set up the users and groups to provide the
appropriate permissions, then set the file permissions accordingly.

755 permissions are safe enough. Full read access and only user write
access.

Not at all. Would you want someone else to have access to your PHP code
or private files? Say someone who signed onto the machine with SSH or
(shudder) telnet? 755 gives them those rights.

Firstly they can't as that is all firewalled out, secondly so what? My
code ain't that great anyway :-)

If they were private files they wouldn't be accessible by a web server
anyway.

>>I'd suggest you get a book on Linux Administration. It will help you
with a lot of different things. And I'm not being sarcastic about
the suggestion; learning some of the basics of Linux administration
will help you understand a lot of this better - it can be quite
confusing.

[The Natural Philosopher]

Adam Baker wrote:

On Sep 18, 9:49 am, Jerry Stuckle <[e-mail]:

>Adam Baker wrote:

>>On Sep 14, 5:06 am, Jerry Stuckle <[e-mail]:
Adam Baker wrote:
Hello,
I'm writing a site where a handful of people will be able to edit
the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)
Thanks,
Adam
The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's completely
between Apache and the user.
And beware that unless you implement your own security, any of those
people will be able to edit any of the files.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?
It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?
Thanks,
Adam

Every process in the machine runs under a specific user. That's what
determines the permissions available to the process.

No one "owns" Apache. There is a user (or even more than one) which
owns the files Apache uses to run. And there is a user for the Apache
process. They may or may not be the same.

And chmod to 777 is highly dangerous - it allows anyone on your server
to read and write to your files. It should never be done if you value
those files, IMHO.

Rather, you should set up the users and groups to provide the
appropriate permissions, then set the file permissions accordingly.

I'd suggest you get a book on Linux Administration. It will help you
with a lot of different things. And I'm not being sarcastic about the
suggestion; learning some of the basics of Linux administration will
help you understand a lot of this better - it can be quite confusing.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Is there a good Linux book you could recommend? I don't think I've
ever read anything about Linux that didn't presuppose a LOT of
background knowledge.

You cant go wrong with most O'Reilly books. I think there is one on
linux system administration...

>
Thanks,
Adam

[The Natural Philosopher]

Gordon Burditt wrote:

>>> I'm writing a site where a handful of people will be able to edit
the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)
Thanks,
Adam
The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's completely
between Apache and the user.

And beware that unless you implement your own security, any of those
people will be able to edit any of the files.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?

Often it's both.

In a typical PHP application, there are 3 different types of users:

OS users, stored in /etc/passwd.
Database users, perhaps stored in the mysql.user table. Usually a web
application "owns" a database user and uses it on its own behalf,
rather than handing out database users to people who register.
Web users, perhaps stored in some other database table, a text file,
or hardcoded somewhere. The web user is used for things like
identifying posts, and determining who gets to access what private
information.

When a user registers for your web application, you typically give them
a web user and NOT an OS user.

Files are owned by OS users. Anything Apache and PHP can write on
can be written on regardless of the Web user. If you have rules
about what Web user can write on what other Web user's stuff, you
have to write code to enforce it. Web users normally don't have
corresponding OS users.

If you are on a shared host, you may be able to FTP content in using
YOUR OS user but PHP runs as Apache's OS user. The only way to let
both write in the same place is to use mode 777 on directories (unless
they are in a common group, which they usually aren't).

>It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?

Standard UNIX file permissions don't allow a file to have two owners.

But they do allow you to reate a group to which two users only belong,
make the file owned groupwise by that group, and set 775 permissions on
it, for example.

All my PHP files are like that..me oand one other person ina group I
called admins, and teh file is owned y user and group admins..

You can set a sticky bit somewhere in the directory umask to enforce the
group ownership on new files as well..I forget how..must set it up.

>
You don't normally want to give x permission to any *file* that a
web application can write on (as distinguished from *directory*,
which needs x permission). x permission is for executables and
shell scripts.

Yes, but normally it does little harm. Most stuff that isn't a script or
a binary won't execute anyway. PHP does not require its files to be
executable: merely readable.

[Jerry Stuckle]

The Natural Philosopher wrote:

Jerry Stuckle wrote:

>The Natural Philosopher wrote:

>>Jerry Stuckle wrote:
Adam Baker wrote:
On Sep 14, 5:06 am, Jerry Stuckle <[e-mail]:
>Adam Baker wrote:
>>Hello,
>> I'm writing a site where a handful of people will be able to
>>edit
>>the content using PHP scripts (FCKeditor). The content is stored as
>>individual files in a directory. I'd like to validate the "editors"
>>using PHP, cookies, etc.
>> The question is what file permissions I need to allow for the
>>content to be writable by my PHP script. Do I really need to give
>>write permissions to the "other" group. Are all wikis really that
>>vulnerable? (yes, I know that's the point, but for restricted wikis,
>>for instance...)
>>Thanks,
>>Adam
>The only one doing the writing will be the Apache user itself. The
>system doesn't know or care who is using the editor - that's
>completely
>between Apache and the user.
>>
>And beware that unless you implement your own security, any of those
>people will be able to edit any of the files.
>>
>--
>==================
>Remove the "x" from my email address
>Jerry Stuckle
>JDS Computer Training Corp.
>[e-mail]
>==================
>
Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?
>
It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?
>
Thanks,
Adam
>

Every process in the machine runs under a specific user. That's
what determines the permissions available to the process.

No one "owns" Apache.

Well actually someone DOES. Even if its a dumnmy user like 'www-user'
or somesuch.

No, someone owns the Apache Process. You could have 10 different
Apache Processes running, each "owned" by a different user.

>>Unless you are dumb enough to run apache as root..and even then root
'owns it'

A quick trawl through the PS command if you are oin unix, will show
waht it runs as user wise.

Viz n a system here
~$ ps -eadf | grep apache
root 9197 1 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 9208 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 9209 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 9210 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 9213 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 9214 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 9787 9197 0 Sep16 ? 00:00:00 /usr/sbin/apache2 -k
start
www-data 11958 9197 0 Sep17 ? 00:00:00 /usr/sbin/apache2 -k
start

www-data is the user who 'owns' apache and that 'user' must have read
access to any file apache wants to deliver.

And you are looking at the Process.

>>>
There is a user (or even more than one) which
owns the files Apache uses to run. And there is a user for the
Apache process. They may or may not be the same.

And chmod to 777 is highly dangerous - it allows anyone on your
server to read and write to your files. It should never be done if
you value those files, IMHO.

Rather, you should set up the users and groups to provide the
appropriate permissions, then set the file permissions accordingly.
755 permissions are safe enough. Full read access and only user write
access.

Not at all. Would you want someone else to have access to your PHP
code or private files? Say someone who signed onto the machine with
SSH or (shudder) telnet? 755 gives them those rights.

Firstly they can't as that is all firewalled out, secondly so what? My
code ain't that great anyway :-)

If they were private files they wouldn't be accessible by a web server
anyway.

Not the case in a lot of systems. Many have telnet/ssh access enabled
to allow users to access a command line prompt for various things - like
install user software.

And even if the webserver cannot access it, anyone with telnet/ssh
access can.

>

>>>I'd suggest you get a book on Linux Administration. It will help
you with a lot of different things. And I'm not being sarcastic
about the suggestion; learning some of the basics of Linux
administration will help you understand a lot of this better - it
can be quite confusing.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Adam Baker wrote:

On Sep 18, 9:49 am, Jerry Stuckle <[e-mail]:

>Adam Baker wrote:

>>On Sep 14, 5:06 am, Jerry Stuckle <[e-mail]:
Adam Baker wrote:
Hello,
I'm writing a site where a handful of people will be able to edit
the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)
Thanks,
Adam
The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's completely
between Apache and the user.
And beware that unless you implement your own security, any of those
people will be able to edit any of the files.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?
It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?
Thanks,
Adam

Every process in the machine runs under a specific user. That's what
determines the permissions available to the process.

No one "owns" Apache. There is a user (or even more than one) which
owns the files Apache uses to run. And there is a user for the Apache
process. They may or may not be the same.

And chmod to 777 is highly dangerous - it allows anyone on your server
to read and write to your files. It should never be done if you value
those files, IMHO.

Rather, you should set up the users and groups to provide the
appropriate permissions, then set the file permissions accordingly.

I'd suggest you get a book on Linux Administration. It will help you
with a lot of different things. And I'm not being sarcastic about the
suggestion; learning some of the basics of Linux administration will
help you understand a lot of this better - it can be quite confusing.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Is there a good Linux book you could recommend? I don't think I've
ever read anything about Linux that didn't presuppose a LOT of
background knowledge.

Thanks,
Adam

Not really, Adam. They all assume some knowledge, but with a system you
can play with and some internet searches, you can generally wade your
way through them.

I've used "Linux Rute User's Tutorial and Exposition" by Paul Sheer in
the past. Not necessarily the greatest, but it helped me.

I'd recommend you just visit your local bookstore and/or library and
start looking through the books. Look for ones which cover basic
commands (such as chmod) but don't seem to be too far over your head.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Gordon Burditt wrote:

>>> I'm writing a site where a handful of people will be able to edit
the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)
Thanks,
Adam
The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's completely
between Apache and the user.

And beware that unless you implement your own security, any of those
people will be able to edit any of the files.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?

Often it's both.

In a typical PHP application, there are 3 different types of users:

OS users, stored in /etc/passwd.
Database users, perhaps stored in the mysql.user table. Usually a web
application "owns" a database user and uses it on its own behalf,
rather than handing out database users to people who register.
Web users, perhaps stored in some other database table, a text file,
or hardcoded somewhere. The web user is used for things like
identifying posts, and determining who gets to access what private
information.

When a user registers for your web application, you typically give them
a web user and NOT an OS user.

Files are owned by OS users. Anything Apache and PHP can write on
can be written on regardless of the Web user. If you have rules
about what Web user can write on what other Web user's stuff, you
have to write code to enforce it. Web users normally don't have
corresponding OS users.

If you are on a shared host, you may be able to FTP content in using
YOUR OS user but PHP runs as Apache's OS user. The only way to let
both write in the same place is to use mode 777 on directories (unless
they are in a common group, which they usually aren't).

A smart host will make users members of the group owned by the Apache
server. Then you can use 660 (or 770 if it's executable) and be
accessible by the owner and the web server, but not by other users.

>

>It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?

Standard UNIX file permissions don't allow a file to have two owners.

You don't normally want to give x permission to any *file* that a
web application can write on (as distinguished from *directory*,
which needs x permission). x permission is for executables and
shell scripts.

So why not just throw the door wide open to any hacker who could upload
to that file and run whatever scripts he wants? :-)
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Gordon Burditt]

>Files are owned by OS users. Anything Apache and PHP can write on

>can be written on regardless of the Web user. If you have rules
about what Web user can write on what other Web user's stuff, you
have to write code to enforce it. Web users normally don't have
corresponding OS users.

If you are on a shared host, you may be able to FTP content in using
YOUR OS user but PHP runs as Apache's OS user. The only way to let
both write in the same place is to use mode 777 on directories (unless
they are in a common group, which they usually aren't).

A smart host will make users members of the group owned by the Apache
server. Then you can use 660 (or 770 if it's executable) and be
accessible by the owner and the web server, but not by other users.

In a hosted setup, it's likely that there is one instance of Apache,
thus this puts all of the users in the same group. This makes 660
or 770 just as much of a threat as 777. The threats are: other
users, admins, and someone coming in through Apache. The admins
and someone coming in through Apache you can't protect against with
file permissions.

You cannot, for example, have multiple instances of Apache listening on
port 80 of a single IP address, and I thought assigning 255 IP addresses
to a single web server went out with browsers that don't understand
HTTP/1.1 and the Host: header.

>>It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?

Standard UNIX file permissions don't allow a file to have two owners.

You don't normally want to give x permission to any *file* that a
web application can write on (as distinguished from *directory*,
which needs x permission). x permission is for executables and
shell scripts.

>So why not just throw the door wide open to any hacker who could upload
to that file and run whatever scripts he wants? :-)

You'd even consider allowing uploads via HTTP?

>==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[The Natural Philosopher]

Jerry Stuckle wrote:

Gordon Burditt wrote:

>>>> I'm writing a site where a handful of people will be able to edit
the content using PHP scripts (FCKeditor). The content is stored as
individual files in a directory. I'd like to validate the "editors"
using PHP, cookies, etc.
The question is what file permissions I need to allow for the
content to be writable by my PHP script. Do I really need to give
write permissions to the "other" group. Are all wikis really that
vulnerable? (yes, I know that's the point, but for restricted wikis,
for instance...)
Thanks,
Adam
The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's completely
between Apache and the user.

And beware that unless you implement your own security, any of those
people will be able to edit any of the files.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?

Often it's both.

In a typical PHP application, there are 3 different types of users:

OS users, stored in /etc/passwd.
Database users, perhaps stored in the mysql.user table. Usually a web
application "owns" a database user and uses it on its own behalf,
rather than handing out database users to people who register.
Web users, perhaps stored in some other database table, a text file,
or hardcoded somewhere. The web user is used for things like
identifying posts, and determining who gets to access what private
information.

When a user registers for your web application, you typically give them
a web user and NOT an OS user.
Files are owned by OS users. Anything Apache and PHP can write on
can be written on regardless of the Web user. If you have rules
about what Web user can write on what other Web user's stuff, you
have to write code to enforce it. Web users normally don't have
corresponding OS users.

If you are on a shared host, you may be able to FTP content in using
YOUR OS user but PHP runs as Apache's OS user. The only way to let
both write in the same place is to use mode 777 on directories (unless
they are in a common group, which they usually aren't).

A smart host will make users members of the group owned by the Apache
server. Then you can use 660 (or 770 if it's executable) and be
accessible by the owner and the web server, but not by other users.

>>

>>It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?

Standard UNIX file permissions don't allow a file to have two owners.

You don't normally want to give x permission to any *file* that a
web application can write on (as distinguished from *directory*,
which needs x permission). x permission is for executables and
shell scripts.

So why not just throw the door wide open to any hacker who could upload
to that file and run whatever scripts he wants? :-)

How, if it is write protected?

[Jerry Stuckle]

Gordon Burditt wrote:

>>Files are owned by OS users. Anything Apache and PHP can write on
can be written on regardless of the Web user. If you have rules
about what Web user can write on what other Web user's stuff, you
have to write code to enforce it. Web users normally don't have
corresponding OS users.

If you are on a shared host, you may be able to FTP content in using
YOUR OS user but PHP runs as Apache's OS user. The only way to let
both write in the same place is to use mode 777 on directories (unless
they are in a common group, which they usually aren't).

A smart host will make users members of the group owned by the Apache
server. Then you can use 660 (or 770 if it's executable) and be
accessible by the owner and the web server, but not by other users.

In a hosted setup, it's likely that there is one instance of Apache,
thus this puts all of the users in the same group. This makes 660
or 770 just as much of a threat as 777. The threats are: other
users, admins, and someone coming in through Apache. The admins
and someone coming in through Apache you can't protect against with
file permissions.

Incorrect. There are ways of keeping each website code within it's own
directory, i.e. the open_basedir can be set on a per-virtual host (or
per-directory) basis. Properly set, PHP will not be able to access
files of another website.

You cannot, for example, have multiple instances of Apache listening on
port 80 of a single IP address, and I thought assigning 255 IP addresses
to a single web server went out with browsers that don't understand
HTTP/1.1 and the Host: header.

I didn't say anything about multiple instances on port 80, did I?

There are 65,535 ports available - and all but the first 4096 (0-4095)
are available to anyone who wants them. Port 80 just happens to be the
default port for the http: protocol.

>>>It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?
Standard UNIX file permissions don't allow a file to have two owners.

You don't normally want to give x permission to any *file* that a
web application can write on (as distinguished from *directory*,
which needs x permission). x permission is for executables and
shell scripts.

>So why not just throw the door wide open to any hacker who could upload
to that file and run whatever scripts he wants? :-)

You'd even consider allowing uploads via HTTP?

Sure. Protections can be established.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

The Natural Philosopher wrote:

Jerry Stuckle wrote:

>Gordon Burditt wrote:

>>>>> I'm writing a site where a handful of people will be able to
>edit
>the content using PHP scripts (FCKeditor). The content is stored as
>individual files in a directory. I'd like to validate the "editors"
>using PHP, cookies, etc.
> The question is what file permissions I need to allow for the
>content to be writable by my PHP script. Do I really need to give
>write permissions to the "other" group. Are all wikis really that
>vulnerable? (yes, I know that's the point, but for restricted wikis,
>for instance...)
>Thanks,
>Adam
The only one doing the writing will be the Apache user itself. The
system doesn't know or care who is using the editor - that's
completely
between Apache and the user.
>
And beware that unless you implement your own security, any of those
people will be able to edit any of the files.
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Thanks for your reply. I am quite ignorant here, so I will see whether
I can even ask a coherent follow-up. So the PHP script is run by the
Apache user. Is that the user that owns Apache, or a special username?

Often it's both.

In a typical PHP application, there are 3 different types of users:

OS users, stored in /etc/passwd.
Database users, perhaps stored in the mysql.user table. Usually a web
application "owns" a database user and uses it on its own behalf,
rather than handing out database users to people who register.
Web users, perhaps stored in some other database table, a text file,
or hardcoded somewhere. The web user is used for things like
identifying posts, and determining who gets to access what private
information.

When a user registers for your web application, you typically give them
a web user and NOT an OS user. Files are owned by OS users. Anything
Apache and PHP can write on
can be written on regardless of the Web user. If you have rules
about what Web user can write on what other Web user's stuff, you
have to write code to enforce it. Web users normally don't have
corresponding OS users.

If you are on a shared host, you may be able to FTP content in using
YOUR OS user but PHP runs as Apache's OS user. The only way to let
both write in the same place is to use mode 777 on directories (unless
they are in a common group, which they usually aren't).

A smart host will make users members of the group owned by the Apache
server. Then you can use 660 (or 770 if it's executable) and be
accessible by the owner and the web server, but not by other users.

>>>
It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?

Standard UNIX file permissions don't allow a file to have two owners.

You don't normally want to give x permission to any *file* that a
web application can write on (as distinguished from *directory*,
which needs x permission). x permission is for executables and
shell scripts.

So why not just throw the door wide open to any hacker who could
upload to that file and run whatever scripts he wants? :-)

How, if it is write protected?

If it's 777, it's not write protected. And even if it's 755 and owned
by the Apache user, you can still upload to it, but anyone will be able
to execute it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[The Natural Philosopher]

Jerry Stuckle wrote:

>You cannot, for example, have multiple instances of Apache listening on
port 80 of a single IP address, and I thought assigning 255 IP addresses
to a single web server went out with browsers that don't understand
HTTP/1.1 and the Host: header.

I didn't say anything about multiple instances on port 80, did I?

Actually you can, and often do, have multiple instances of Apache
(effectively) listening on port 80..

That's how virtual hosting and load balancing works.

[dshesnicky]

>
755 permissions are safe enough. Full read access and only user write
access.

Why give 755 for "file permissions I need to allow for the content to
be
writable by my PHP script."? Use 644 for read and write permissions by
user
and read by the world. Using 755 adds executable permissions which
aren't
needed on data files only scripts and binaries.

Don

[Jerry Stuckle]

The Natural Philosopher wrote:

Jerry Stuckle wrote:

>>You cannot, for example, have multiple instances of Apache listening on
port 80 of a single IP address, and I thought assigning 255 IP addresses
to a single web server went out with browsers that don't understand
HTTP/1.1 and the Host: header.

I didn't say anything about multiple instances on port 80, did I?

Actually you can, and often do, have multiple instances of Apache
(effectively) listening on port 80..

That's how virtual hosting and load balancing works.

No. You can only have one instance of Apache running on port 80 on a
single machine.

Virtual hosting works because that one instance has several hosts
defined. But it is still only one instance.

Load balancing works because the instances of Apache are on different
systems.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[The Natural Philosopher]

Jerry Stuckle wrote:

The Natural Philosopher wrote:

>Jerry Stuckle wrote:

>>>You cannot, for example, have multiple instances of Apache listening on
port 80 of a single IP address, and I thought assigning 255 IP
addresses
to a single web server went out with browsers that don't understand
HTTP/1.1 and the Host: header.
I didn't say anything about multiple instances on port 80, did I?

Actually you can, and often do, have multiple instances of Apache
(effectively) listening on port 80..

That's how virtual hosting and load balancing works.

No. You can only have one instance of Apache running on port 80 on a
single machine.

Virtual hosting works because that one instance has several hosts
defined. But it is still only one instance.

Load balancing works because the instances of Apache are on different
systems.

Semantics.

You can chain more listeners than one to a single port. At what point
that becomes 'more than one instance tied to a port' as against 'one OS
routine vectoring calls to multiple processes' is a moot one.

My process list for apache shows this:-

ps -eadf| grep apache
root 9310 1 0 Jul16 ? 00:00:00 /usr/sbin/apache
www-data 22302 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22303 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22304 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22305 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22306 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22807 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22892 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 23339 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 23417 9310 0 Sep17 ? 00:00:00 /usr/sbin/apache
www-data 23418 9310 0 Sep17 ? 00:00:00 /usr/sbin/apache

i.e 10 instances of apache on ONE server instance are running. Plus the
original spawner. This is on an IDLE web server..the spare processes are
there to add load capacity without the overhead of a fork().

It is perfectly possible for more than one process to bind() to the same
socket, provided that the socket options are set up that way. The only
proviso being that the processes understand each other and work
co-operatively. In essence its no more complex than e.g sharing a
hardaware interrupt: All processes that are attached to that interrupt
wake up, and one of them decides 'its mine' and takes it whilst the
others go back to sleep..

I am fairly sure apache does this routinely as above:

[Sanders Kaufman]

"The Natural Philosopher" <[e-mail] in message
news:11***************@proxy00.news.clara.net...

It is perfectly possible for more than one process to bind() to the same
socket, provided that the socket options are set up that way. The only
proviso being that the processes understand each other and work
co-operatively. In essence its no more complex than e.g sharing a
hardaware interrupt:

That's an *excellent* analogy - and we all know what happens when you try to
put more than one active device on an interrupt - hickups, stalls and
lockups.
The only way it works is if all but one of the devices remain mostly
inactive, only occasionally asking (politely) for the channel.

[Jerry Stuckle]

The Natural Philosopher wrote:

Jerry Stuckle wrote:

>The Natural Philosopher wrote:

>>Jerry Stuckle wrote:

You cannot, for example, have multiple instances of Apache
listening on
port 80 of a single IP address, and I thought assigning 255 IP
addresses
to a single web server went out with browsers that don't understand
HTTP/1.1 and the Host: header.
>

I didn't say anything about multiple instances on port 80, did I?
Actually you can, and often do, have multiple instances of Apache
(effectively) listening on port 80..

That's how virtual hosting and load balancing works.

No. You can only have one instance of Apache running on port 80 on a
single machine.

Virtual hosting works because that one instance has several hosts
defined. But it is still only one instance.

Load balancing works because the instances of Apache are on different
systems.

Semantics.

No, much more than semantics. If you have multiple instances of Apache
running on different ports, those processes can have different owners.
A single instance of Apache only has one owner.

You can chain more listeners than one to a single port. At what point
that becomes 'more than one instance tied to a port' as against 'one OS
routine vectoring calls to multiple processes' is a moot one.

My process list for apache shows this:-

ps -eadf| grep apache
root 9310 1 0 Jul16 ? 00:00:00 /usr/sbin/apache
www-data 22302 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22303 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22304 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22305 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22306 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22807 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22892 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 23339 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 23417 9310 0 Sep17 ? 00:00:00 /usr/sbin/apache
www-data 23418 9310 0 Sep17 ? 00:00:00 /usr/sbin/apache

i.e 10 instances of apache on ONE server instance are running. Plus the
original spawner. This is on an IDLE web server..the spare processes are
there to add load capacity without the overhead of a fork().

Sure. They are different processes.

It is perfectly possible for more than one process to bind() to the same
socket, provided that the socket options are set up that way. The only
proviso being that the processes understand each other and work
co-operatively. In essence its no more complex than e.g sharing a
hardaware interrupt: All processes that are attached to that interrupt
wake up, and one of them decides 'its mine' and takes it whilst the
others go back to sleep..

I am fairly sure apache does this routinely as above:

Or does the main process get the request and hand it off to the
appropriate process? This would seem to be much lower overhead. I'm
not sure about it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[dshesnicky]

You can set a sticky bit somewhere in the directory umask to enforce the
group ownership on new files as well..I forget how..must set it up.

That's the setgid bit not the sticky bit which is different.

If you do a "chmod g+s dir" it will turn that on, or put a 2 in front
of the octal permissions "chmod 2755 dir".

[The Natural Philosopher]

Jerry Stuckle wrote:

The Natural Philosopher wrote:

>Jerry Stuckle wrote:

>>The Natural Philosopher wrote:
Jerry Stuckle wrote:

>You cannot, for example, have multiple instances of Apache
>listening on
>port 80 of a single IP address, and I thought assigning 255 IP
>addresses
>to a single web server went out with browsers that don't understand
>HTTP/1.1 and the Host: header.
>>
>
I didn't say anything about multiple instances on port 80, did I?
>

Actually you can, and often do, have multiple instances of Apache
(effectively) listening on port 80..

That's how virtual hosting and load balancing works.

No. You can only have one instance of Apache running on port 80 on a
single machine.

Virtual hosting works because that one instance has several hosts
defined. But it is still only one instance.

Load balancing works because the instances of Apache are on different
systems.

Semantics.

No, much more than semantics. If you have multiple instances of Apache
running on different ports, those processes can have different owners. A
single instance of Apache only has one owner.

>You can chain more listeners than one to a single port. At what point
that becomes 'more than one instance tied to a port' as against 'one
OS routine vectoring calls to multiple processes' is a moot one.

My process list for apache shows this:-

ps -eadf| grep apache
root 9310 1 0 Jul16 ? 00:00:00 /usr/sbin/apache
www-data 22302 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22303 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22304 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22305 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22306 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22807 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 22892 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 23339 9310 0 Sep16 ? 00:00:00 /usr/sbin/apache
www-data 23417 9310 0 Sep17 ? 00:00:00 /usr/sbin/apache
www-data 23418 9310 0 Sep17 ? 00:00:00 /usr/sbin/apache

i.e 10 instances of apache on ONE server instance are running. Plus
the original spawner. This is on an IDLE web server..the spare
processes are there to add load capacity without the overhead of a
fork().

Sure. They are different processes.

>It is perfectly possible for more than one process to bind() to the
same socket, provided that the socket options are set up that way. The
only proviso being that the processes understand each other and work
co-operatively. In essence its no more complex than e.g sharing a
hardaware interrupt: All processes that are attached to that interrupt
wake up, and one of them decides 'its mine' and takes it whilst the
others go back to sleep..

I am fairly sure apache does this routinely as above:

Or does the main process get the request and hand it off to the
appropriate process? This would seem to be much lower overhead. I'm
not sure about it.

Yes and no. The main process is, I think, the operating system.I.e. the
ten processes register themselves as waiting for a SYN packet on port
80..the OS notes that, and when one arrives simply resumes all of them.
The first one to get there accepts the connection and the rest wake up,
find nothing to do and go back to sleep probably.

[The Natural Philosopher]

ds********@yahoo.com wrote:

>You can set a sticky bit somewhere in the directory umask to enforce the
group ownership on new files as well..I forget how..must set it up.

That's the setgid bit not the sticky bit which is different.

If you do a "chmod g+s dir" it will turn that on, or put a 2 in front
of the octal permissions "chmod 2755 dir".

I always got that one wrong.

So many stupid bits to remember..

[Gordon Burditt]

>>>>You cannot, for example, have multiple instances of Apache listening on

>>>>port 80 of a single IP address, and I thought assigning 255 IP
addresses
to a single web server went out with browsers that don't understand
HTTP/1.1 and the Host: header.
>

I didn't say anything about multiple instances on port 80, did I?
Actually you can, and often do, have multiple instances of Apache
(effectively) listening on port 80..

That's how virtual hosting and load balancing works.

No. You can only have one instance of Apache running on port 80 on a
single machine.

Virtual hosting works because that one instance has several hosts
defined. But it is still only one instance.

Load balancing works because the instances of Apache are on different
systems.

Semantics.

You can chain more listeners than one to a single port. At what point
that becomes 'more than one instance tied to a port' as against 'one OS
routine vectoring calls to multiple processes' is a moot one.

Let's see you set it up so that (a) all of the processes have
different user ids, none of them root, (b) the dispatcher process(es)
actually doing the listen() is(are) not running as root, (c) no use
of setuid-root programs, and (d) the dispatcher is able to dispatch
the requests to the process with the correct user id (based on the
Host: header).

[Gordon Burditt]

>You cannot, for example, have multiple instances of Apache listening on

>port 80 of a single IP address, and I thought assigning 255 IP addresses
to a single web server went out with browsers that don't understand
HTTP/1.1 and the Host: header.

I didn't say anything about multiple instances on port 80, did I?

There are 65,535 ports available - and all but the first 4096 (0-4095)
are available to anyone who wants them. Port 80 just happens to be the
default port for the http: protocol.

Have you ever seen an advertised (with paid advertising) URL for a
non-default port? Nobody's going to take it seriously, or even
type it correctly. It might be OK if you also own the one on port
80 and the only links to the other one are yours. It's also not
too bad for a purely testing site, but it's not one a hosting company
is actually going to be able to sell.

>>>>It would seem, then, that I would want to give rwx permissions for the
content files to that user alone (and myself), not do a chmod 777. Is
that right?
Standard UNIX file permissions don't allow a file to have two owners.

You don't normally want to give x permission to any *file* that a
web application can write on (as distinguished from *directory*,
which needs x permission). x permission is for executables and
shell scripts.

>>So why not just throw the door wide open to any hacker who could upload
to that file and run whatever scripts he wants? :-)

You'd even consider allowing uploads via HTTP?

Sure. Protections can be established.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[dshesnicky]

I always got that one wrong.

So many stupid bits to remember..

Agreed. It's hard if your not constantly in flipping em. For that one
remember "set group".

[Jerry Stuckle]

Gordon Burditt wrote:

>>You cannot, for example, have multiple instances of Apache listening on
port 80 of a single IP address, and I thought assigning 255 IP addresses
to a single web server went out with browsers that don't understand
HTTP/1.1 and the Host: header.

I didn't say anything about multiple instances on port 80, did I?

There are 65,535 ports available - and all but the first 4096 (0-4095)
are available to anyone who wants them. Port 80 just happens to be the
default port for the http: protocol.

Have you ever seen an advertised (with paid advertising) URL for a
non-default port? Nobody's going to take it seriously, or even
type it correctly. It might be OK if you also own the one on port
80 and the only links to the other one are yours. It's also not
too bad for a purely testing site, but it's not one a hosting company
is actually going to be able to sell.

Actually, yes I have - for various reasons. For instance, my Windows
VPS's use a different port for control. And I have seen it used for
links from the main site, i.e. when you want to run IIS and Apache on
the same (Windows) machine, as I'm doing on one site right now. It
works fine, and people do link to it. In fact, port 8080 is commonly
used as a secondary http port.

So I wouldn't suggest you make blanket statements like that. While not
common, it is done, and it works quite well.

>>>>>It would seem, then, that I would want to give rwx permissions for the
>content files to that user alone (and myself), not do a chmod 777. Is
>that right?
Standard UNIX file permissions don't allow a file to have two owners.
>
You don't normally want to give x permission to any *file* that a
web application can write on (as distinguished from *directory*,
which needs x permission). x permission is for executables and
shell scripts.

So why not just throw the door wide open to any hacker who could upload
to that file and run whatever scripts he wants? :-)
You'd even consider allowing uploads via HTTP?

Sure. Protections can be established.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================