suexec & directory permissions (ownership) problem

[raphidae]

I'm migrating from Apache, and I've hit a problem on the suexec configuration.


My directory layout is as follows:

/var/www/:

drwxrwxr-t 4 root user 512 Apr 2 11:15 www.example.com

/var/www/www.example.com/:

-rw-r--r-- 1 user user 0 May 10 2007 .htpasswd
drwxr-xr-x 2 root www 512 Apr 2 12:00 logs
drwxrwxr-t 8 root user 512 Mar 17 18:39 root

/var/www/www.example.com/root/:

drwxr-xr-x 2 root www 2560 Apr 2 06:00 stats


'user' has (chroot) access to '/var/www/www.example.com/' via FTP.

This setup accomplishes the following:

-'user' cannot delete/rename '/var/www/www.example.com/root'.

-'user' cannot delete/rename/change anything in '/var/www/www.example.com/root/stats/'

-'user' cannot delete/rename/change anything in '/var/www/www.example.com/logs/'

-'user' can write as usual in '/var/www/www.example.com/root' and view the logs etc.


Apache expects the docroot to be there, so it'd be a problem if an user deleted/renamed it, as with the logfiles. Scripts expect the /stats/ directory to be there. I do not trust 'user' to leave them alone or even know what he's doing.

My problems:

-LiteSpeed writes the logfiles as 'www', while Apache used to write them as root.
-suexec only offers the option to set the uid to that of the docroot. The docroot is owned by root, while the suexec uid needs to be 'user'.

Please advise on how to solve this in the best way.

Also, it seems that normally the docroot is owned by 'user', so I'm curious as to how others prevent customers deleting/renaming it.

 

[mistwang]

If you use LiteSpeed together with Apache httpd.conf, LiteSpeed will follow "User", "Group" or "suexecUserGroup" directive in httpd.conf instead of using UID of docroot.

Litespeed write log file as "www" because the child lshttpd process running as "www" need to dynamically open/close and write to the file for the sake of scalability, especially when there are thousands of vhosts hosted. Apache keep all log files open all the time.

I think the best way is to simplify your directory structure. Let the doc root own by "user", and user can do whatever he want inside it, put other directories with special permission requirements outside of the docroot, use "Alias" to map those directories to desired URI.

 

[raphidae]

Is there any reason why setting the uid to something else as the owner of docroot is only available when using an Apache httpd.conf?

And one probem I'd have with the aliasing suggestion is that users will need access to the logs by FTP as well.

 

[mistwang]

And one probem I'd have with the aliasing suggestion is that users will need access to the logs by FTP as well.

Will a symbolic link work? user only need read permission on that file I guess.

 

[raphidae]

Will a symbolic link work? user only need read permission on that file I guess.

No, the user could delete the link as it is the owner of the parent directory.

This is why I have the docroot owned by root and the sticky bit set so that while users have read/write rights by group, they cannot delete/rename stuff not owned by themselves.

 

[mistwang]

Make user's home directory owned by root with sticky bit set.
create a doc root directory under the home directory owned by user.
create a log directory under the home directory owned by "www:user".
ftp should be able to read log files while user cannot remove the log directory.

 

[raphidae]

Make user's home directory owned by root with sticky bit set.
create a doc root directory under the home directory owned by user.
create a log directory under the home directory owned by "www:user".
ftp should be able to read log files while user cannot remove the log directory.

I'll try this. However, it would be easier if I could just pick an uid for suexec The functionality for this is obviously implemented, but just inaccessible for non-httpd.conf users.

 

[raphidae]

Changing the directory structure as you suggested works, however now I have a problem with the logfiles.

I have created a directory 'logs' (www:www) under $VH_ROOT (www:www). Now the access logfile is created with root:www and the error logfile with www:user, while I was expecting both to be www:www like I observed earlier.

Also these files remain 0 bytes, so there is defenately a problem somewhere.

However, there is nothing in the server logs indicating a problem (access.log, stderr.log & error.log). Earlier when I entered an invalid URI for an error document I couldn't find anything either. Am I missing another logfile somewhere?

Please advise.

 

[mistwang]

permission problem with parent directories I think.
Those files are created by lshttpd running as root, while lshttpd running as www cannot open them for writing.

 

[raphidae]

permission problem with parent directories I think.
Those files are created by lshttpd running as root, while lshttpd running as www cannot open them for writing.

The permissions are as follows:

drwxr-xr-x 2 www www 512 Apr 4 04:54 .
drwxr-xr-t 6 www www 512 Apr 4 04:07 ..
-rw-r--r-- 1 root www 0 Apr 4 04:54 access_log
-rw-r--r-- 1 www user 0 Apr 4 04:54 error_log

This is how the files are created. I can see how lshttpd as www cannot write to access_log, but then my question is why the file is created root:www with 0644 in the first place. Especially because it was created www:www earlier.

The error log should be writable, but why is the group 'user'? None of the parents in the tree have that group and no lshttpd runs with that group.

Also, there is absolutely no mention of an error creating or writing to logfiles in the server log at the highest debug level while the normal stuff is written OK. Is this normal behaviour?

 

[mistwang]

I don't know why, the access_log and error_log should be created as www:www or www:user.
created with group "user" because most time "user" need to get the read permission when umask is set to 027, it follows the vhost suexec group.

 

[raphidae]

Well, the access log is created root:www. If I set chmod g+w on it, it will log accesses, but the fact that lsws creates a log file that it can't write to is weird and I need it to work without me fixing it.

I temporarily removed the sticky bit and set the 'logs' directory mode 0777 to see if that makes any difference, but it does not.

drwxrwxrwx 2 www www 512 Apr 7 21:06 .
drwxr-xr-x 6 www www 512 Apr 4 04:07 ..
-rw-r--r-- 1 root www 0 Apr 7 21:06 access_log
-rw-r--r-- 1 www user 0 Apr 7 21:06 error_log

I suspect there is a problem chown-ing the access log to 'www', but again, there is absolutely nothing suggesting a problem in the server log.

The error log is even weirder, if I set 'ExtApp Set UID Mode' to 'Server UID' the file is still created as www:user. And nothing is written to it, even when I set it umode 0666.

 

[raphidae]

Actually, I just noticed that I had debug logging set to 'MEDIUM' and when I set it to 'HIGH' the server error log was filled with literally thousands of:

2008-04-07 21:26:04.250 [DEBUG] Failed to execute 'mpstat' command: No such file or directory

and

2008-04-07 21:26:05.239 [DEBUG] Failed to execute 'curl' command: No such file or directory

As I'm running FreeBSD there is no 'mpstat' and there is no port for it. I'm running the FreeBSD version of LiteSpeed Enterprise, so why's it looking for something that can't be there?

There is a port for 'curl', but why does LiteSpeed need it? Is it a requirement?

Also, could this be related to my logging problems? No other problems are logged.

 

[mistwang]

mpstat output is used as part of the server status in our real time statistic report, missing mpstat command will not cause any trouble. You can safely ignore it.

the error regading "curl" command is strange, we never use it inside lshttpd process. Does it appear repeatedly?

 

[mistwang]

updated 3.3.10 release package should have fixed the access log ownership problem.
The error log ownership is fine, no need to change it.

 

[raphidae]

mpstat output is used as part of the server status in our real time statistic report, missing mpstat command will not cause any trouble. You can safely ignore it.

the error regading "curl" command is strange, we never use it inside lshttpd process. Does it appear repeatedly?

Not as much as the 'mpstat' error. I installed the curl port, and that seems to have fixed it.

And 3.3.10 fixes the log problem, thanks!