It is already addressed, thanks for the additional idea, ill have it output to the debug log if uu omits a file. I'll also have uu skip the md5 checking of files that arent in the "allowed extensions" list.

Care to cite references? Or to explain to me how one 'seals' a directory other than using file permissions? If Apache isn't running suexec, it certainly isn't running chrooted, and you'd have to have a separate apache parent per home dir.

File permission (and open_basedir) is all you need.

If Level 0 is the root dir of your account:
dir_level user/group chmod
-2 root/root 751
-1 UID/http 750
0 UID/GID 755

Suexec defined per virtualhost to UID/GID (you need a unique UID/GID per user obviously)
open_basedir restriction on Level 0 directory restricts PHP within the user's dir.

That's all you need to prevent user A to access user's B tree through CGI/PHP. the o+x on level -2 allows suexec to work but prevents all other access except to the webserver's user. No rights for others at level -1 prevents anybody else than the webserver to do anything.

Since nobody is running anything as the webserver except PHP and since your open_basedir restricts access to anything outside the virtualhost tree there's no security loop.

While you may not be able to see the other user's files while you're logged in via FTP, they are certainly still there. FTPd's have historically had a lot more options to chroot post-connect. Apache doesn't.

That is correct but as explained above nobody can access them.

Try it, it works.


- Jeff


Edit: can't make up my mind if level -1 is useful or not... I think I came up with it 5+ years ago when I didn't implement suexec, anyway it can't hurt. I'd need to dig into my configuration to understand why I did half of what I did

Fangorn wrote:Suexec defined per virtualhost to UID/GID (you need a unique UID/GID per user obviously)
open_basedir restriction on Level 0 directory restricts PHP within the user's dir.
...
That's all you need to prevent user A to access user's B tree through CGI/PHP. the o+x on level -2 allows suexec to work but prevents all other access except to the webserver's user. No rights for others at level -1 prevents anybody else than the webserver to do anything.

suexec needs permissions?

It's setuid to root which changes uid to you. It needs no permissions other than that you yourself can view the files.

And why are you even saying that you use it, when two posts ago you said no one uses it? You seem to have reversed your position.

Fangorn wrote:Since nobody is running anything as the webserver except PHP and since your open_basedir restricts access to anything outside the virtualhost tree there's no security loop.

OK, somewhere you went from me talking about ISPs at large, where I cited supported policies from two major hosting providers that said the same as I did, to talking about some odd setup you once did 5 years ago.

In the world at large, ISPs allow a lot more than PHP scripts. It is one language of many used for web apps. The magic open_basedir function only limits what PHP scripts under mod_php can do. It does nothing at all to prevent any other script (Ruby, Python, Perl, Java, etc...) from reading your files.

If you are stating that you think all large ISPs run mod_php instead of php as a cgi, but don't run mod_python, mod_perl, etc, then that's a highly unlikely claim.

MattM wrote:Negative, observe the source code for the addon unzipper uu uses:

Code: Select all

if (extention != ".exe" && extention != ".com" && extention != ".jar" && extention != ".vbs" && extention != ".bat")
               {
                  DebugLine("Writing File: " + directoryName+@""+fileName);
                  FileStream streamWriter = File.Create(directoryName+@""+fileName);

As you can see I have thought of this particular securety concern.

Best practice is generally to specify what you allow, not what you deny.

Consider that a hostile addon could use extensions like "pif", "com", "cmd", etc. The list of possibly malicious extensions is unending. The list of known good ones is short.

I suggest instead coding a small array of allowed extensions, and searching this table to determine if the file is allowed.

BTW, is "extention" a British spelling variation?

Brimstone wrote:http://wiki.dreamhost.com/index.php/Suexec
http://faq.siteground.com/faq/file-permissions.html

You say you have all of these qualifications, but instead of
posting anything insightful about how to actually correct
the problem of running mod_php in apache and having to have
files writable by the apache process to be able to save
information to the disk, you post two links to SUEXEC, which
CANNOT set the UID of processes that are being held by
mod_php.


If you had outlined something like the later poster did
using mod_phps safe_mode features or explain how some leet
user / group permission setup could fix the issue, it would
have made your post have more merit than saying "oh look

suexec lawl"

Most web servers that are setup by even highly secure hosts,
will have to support mod_php for their customers. Apache
will run as user nobody in the mod_php environment and many
of these web hosts will allow write support to their users
webspace by apache and php scripts. No matter how you
configure apache, if you want to be able to save a file to
disk through a web utility, you will have files that will be
writable by the apache process, which in itself is insecure.


I don't care if you have a per user apache parent running in
a chroot'd environment for each user on your server. When a
user decides to upload a script that can save a file from a
personal computer to the web server harddrive, no amount of
unix permission finesse will be prevent you from exploiting
a script that is not secure to begin with.


ealier in the thread you wrote,

I'd even go so far as to think that ideally, uniadmin should
check for world-writable directories within its structure
and refuse to operate if there are any.

How do you propose that users take advantage of the ability
to push addons to their guild mates without being able to
upload files to their admin utility?

You have quite the issue there; you need to be able to allow
users to upload and write files to a directory but at the
same time not have directories writable by the apache
rocess.