You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by ld...@ulysium.net on 2003/05/09 00:50:07 UTC
[users@httpd] small Suexec problem
Hello all,
I've been lurking on the list and didn't find any hints to help me with my
little suexec problem.
the system is tru64 unix, apache 2.0.45
I was able to run small test cgi scripts without suexec enabled
(disabling the suexecusergroup directive)
but with suexec re-enabled, it seems it's not even getting close to the
script itself for execution.
What I get is an error in the suexec log that says:
cannot get current working directory
that's after it found the correct uid and gid specified by the
suexecusergroup, which do match the system's for that user.
I tried something a little odd to test a hunch I had, but it didn't reveal
what I thought it would: I sued to the httpd user and moved into the apache
root folder, then tried to su from that location to the user which is meant
to execute the scripts, and it worked fine, I could even do it from the bin
folder located in the apache root folder, and I could move to the location
of the script as the script's user from either location inside apache's
root.
At least I thought I'd get a similar error to the suexec one if I tried to
do something a little similar manually, by changing from the httpd user to
the non-privileged one supposed to run the script. If it was a permission
issue, I thought this would've been revealed that way...
I have no symlinks in the path to the cgis and apache's root, nor to the
document root in the user's account, I have the full path defined in the
config, avoiding any symlinks that could get in the way.
Is there anything else I need to look for?
--
Didier Godefroy
mailto:dg@ulysium.net
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by ld...@ulysium.net.
>> now I can't su to root from httpd, that's a security restriction of the su
>> command on tru64 which only allows members of the system group to su root
>
> Well, but the setuid bit works (otherwise suexec wouldn't run until the
> error).
Sure, suexec wouldn't use su, it would use a system call directly, so the
tru64 security issue doesn't come into play.
> I have the impression, getcwd goes from root up to the cwd, perhaps trying
> to resolve symlinks or checking the path for other things. It seems you have
> to make the parent directories readable for the user. Can you test it?
I did, I added the r bit all the way through the path to the script and that
made it work, so that proves having only the x bit isn't enough for getcwd()
to work. That sucks, I wanted to prevent directory contents from being
listable, only allow the travel through the folders...
--
Didier Godefroy
mailto:dg@ulysium.net
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by André Malo <nd...@perlig.de>.
* <ld...@ulysium.net> wrote:
<snip explanations>
thanks.
> Now like I said, with suexec disabled, this script actually runs fine (it's
> just printing the environment)
Yep, the problem is inside suexec.
>> Are you manually able to switch to the directory as httpd user, su to root,
>> su to the script's desired user and `pwd`?
>
> I can su to httpd, I did it from within apache's root folder
> (/usr/local/apache) and also in the apache/bin just in case, then I have no
> problem cd-ing to / /srv /srv/sites and all the way to the final script
> location of /srv/sites/p/paradox
> I can't do ls in that location of course, because the r bit isn't set, but I
> can do the pwd and get /srv/sites/p/paradox as it should be
> The pwd command uses the system call getcwd() doesn't it?
I'd guess.
> now I can't su to root from httpd, that's a security restriction of the su
> command on tru64 which only allows members of the system group to su root
Well, but the setuid bit works (otherwise suexec wouldn't run until the
error).
> but I can (with the password) su from httpd to the final user paradox in the
> script location, the only thing that doesn't work there is the pwd which
> gives the same error as suexec when trying to execute the script
ah!
> shell-init: could not get current directory: getcwd: cannot access parent
> directories: Permission denied
>
> but those parent folders have the x bit set for other all the way to /
> so what's holding it back then?
I have the impression, getcwd goes from root up to the cwd, perhaps trying
to resolve symlinks or checking the path for other things. It seems you have
to make the parent directories readable for the user. Can you test it?
Does `man getcwd` on the system say something about such problems? (doesn't
on my linux box).
nd
--
>I have tried using ErrorDocument 401, but doesn't work.
^^^^^^^^^^^^^
Oh dear. What does it do - lounge around on the couch all day drinking
beer and watching TV? -- "Kash" und Alan J. Flavell in ciwsu
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by ld...@ulysium.net.
A little more info after trying something:
I left all the r-x for other in the path to the script location and removed
the r bit off the folder containing the scripts itself and chmoded a test
script to 550. That test script was to write a file and it worked as
expected, a new file was created and data written to it as it should, and
that file is owned by the user/group expected.
So this issue about the getcwd() call from tru64 is that it works if the r
bit isn't on the folder itself but the parent and all the way to the root do
need to have the r bit set (for other) or the getcwd fails.
Perhaps it's possible that linux behave slightly differently... (or perhaps
not)
At least I get to prevent listing contents in a script folder without
preventing the scripts from working, which is what I wanted to do, it's too
bad I can't enforce this on the parent(s) as well.
I hope all this helps others with a similar situation...
--
Didier Godefroy
mailto:dg@ulysium.net
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by ld...@ulysium.net.
>> Update on my suexec situation, although having the x bit set and not the r
>> on a folder doesn't prevent pwd to work, it seems not to be enough for
>> suexec. I added the r bit back to other in all folders in the path to the
>> script and the getcwd now works and lets the script run.
>> This doesn't make sense to me, and it forces to do something I was trying to
>> avoid, which is giving r-x to other, to prevent prying eyes and give each
>> user as much privacy as possible.
>
> As I've guessed. Well, at least we have the reason now archived here. :-)
That's a good thing ;-)
>> Also, when I set suexec up, I gave it a umask of 007 which isn't a problem
>> because all users have their own separate group, but suexec reports a
>> warning about this. No big deal, it's just a warning and it's not a security
>> risk in this case. Is there any way to set the umask for suexec at runtime?
>
> No. I'd recompile with 027.
Well, the next time I recompile, I'll have to remember to do this, but for
now it isn't an issue, as the group can be writable in this case without a
security problem because the group is unique to each user.
>> I really would prefer not to give r-x at least on the parent folder of the
>> script folders, is there any way to do this?
>
> Hmm, this is obviously a system problem. suexec can't do much in that case.
> (just a note: on my linux box it works the way you wanted to go). You may
That's interesting, perhaps a tru64 thing, maybe in the way getcwd() is
implemented...
> have luck in a true64 support forum, perhaps there are similar system calls,
> so you can patch suexec. (If so, a note on the httpd-dev-list or here would
> be fine, so we may consider a suexec change according to this point).
I'm no C programmer, I'm not sure where to go from there, but now that the
issue has been raised and somebody more competent than me probably has read
this, somebody may know an answer to this...
--
Didier Godefroy
mailto:dg@ulysium.net
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by André Malo <nd...@perlig.de>.
* <ld...@ulysium.net> wrote:
> Update on my suexec situation, although having the x bit set and not the r
> on a folder doesn't prevent pwd to work, it seems not to be enough for
> suexec. I added the r bit back to other in all folders in the path to the
> script and the getcwd now works and lets the script run.
> This doesn't make sense to me, and it forces to do something I was trying to
> avoid, which is giving r-x to other, to prevent prying eyes and give each
> user as much privacy as possible.
As I've guessed. Well, at least we have the reason now archived here. :-)
> Also, when I set suexec up, I gave it a umask of 007 which isn't a problem
> because all users have their own separate group, but suexec reports a
> warning about this. No big deal, it's just a warning and it's not a security
> risk in this case. Is there any way to set the umask for suexec at runtime?
No. I'd recompile with 027.
> I really would prefer not to give r-x at least on the parent folder of the
> script folders, is there any way to do this?
Hmm, this is obviously a system problem. suexec can't do much in that case.
(just a note: on my linux box it works the way you wanted to go). You may
have luck in a true64 support forum, perhaps there are similar system calls,
so you can patch suexec. (If so, a note on the httpd-dev-list or here would
be fine, so we may consider a suexec change according to this point).
nd
--
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~ # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord( # André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see; # http://www.perlig.de/ ;
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by ld...@ulysium.net.
Update on my suexec situation, although having the x bit set and not the r
on a folder doesn't prevent pwd to work, it seems not to be enough for
suexec. I added the r bit back to other in all folders in the path to the
script and the getcwd now works and lets the script run.
This doesn't make sense to me, and it forces to do something I was trying to
avoid, which is giving r-x to other, to prevent prying eyes and give each
user as much privacy as possible.
Also, when I set suexec up, I gave it a umask of 007 which isn't a problem
because all users have their own separate group, but suexec reports a
warning about this. No big deal, it's just a warning and it's not a security
risk in this case. Is there any way to set the umask for suexec at runtime?
I really would prefer not to give r-x at least on the parent folder of the
script folders, is there any way to do this?
--
Didier Godefroy
mailto:dg@ulysium.net
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by ld...@ulysium.net.
>>> Hmm. What are the rights of the script directory?
>>
>> / has r-x for other
>> /srv as well
>> /srv/sites has --x for other and is the document root specified for suexec
>
> and for the user itself?
only the folder containing the scripts is actually owned by the final
user/group
That system uses acls (it's tru64), here's the complete rundown of the
perms/acls on this whole path to the script(s)
getacl /
# file: /
# owner: root
# group: system
#
user::rwx
group::r-x
other::r-x
getacl /srv
# file: /srv
# owner: root
# group: system
#
user::rwx
group::r-x
other::r-x
getacl /srv/sites
# file: /srv/sites
# owner: root
# group: httpd
#
user::rwx
group::r-x
other::--x
getacl /srv/sites/p
# file: /srv/sites/p
# owner: root
# group: httpd
#
user::rwx
group::r-x
other::--x
getacl /srv/sites/p/paradox
# file: /srv/sites/p/paradox
# owner: paradox
# group: paradox
#
user::rwx
group::r-x
other::--x
as I mentioned, /srv/sites is what I compiled in suexec as the docroot, and
the http server config has a virtualhost block containing this:
DocumentRoot /srv/p/paradox/home
<Directory "/srv/p/paradox/home">
AllowOverride AuthConfig Limit
Options FollowSymLinks Indexes ExecCGI
Order Deny,Allow
Allow From All
</Directory>
SuexecUserGroup paradox paradox
ScriptAlias /cgi-bin/ /srv/sites/p/paradox/
<Directory "/srv/sites/p/paradox">
AllowOverride AuthConfig Limit
Options FollowSymLinks ExecCGI
Order Deny,Allow
Allow From All
</Directory>
there are more directives in the virtualhost block of course...
I separate the scripts from the rest, although you can see I added ExecCGI
in there, this is for testing, I added it then was able to run scripts in
the home folder, but that won't be allowed later. I even added the ExecCGI
in the directory block of the scriptalias to see if that would help (without
suexec) when I was trying to get scripts to run at first. I left that in for
now but that shouldn't interfere with suexec.
The users on the system have their own group as well, so the goal is to have
cgi scripts chmoded to 550 (or 750) and never have any perms given to other
at all, even in the web docroot, all html/php files won't be given any perms
to other, instead to allow the httpd user access to those files, acls are
added and preset to be automatically inherited at upload time/creation of
the files (this already works perfectly on other systems).
The only thing that's new to my config on this new system is the use of
suexec, besides apache2 replacing apache1.3
the script has those perms right now:
getacl testing
# file: testing
# owner: paradox
# group: paradox
#
user::r-x
group::r-x
other::r-x
but I'll revert this back to nothing for other later, it's the main goal of
using suexec, so no files need any access at all to other
Now like I said, with suexec disabled, this script actually runs fine (it's
just printing the environment)
> Are you manually able to switch to the directory as httpd user, su to root,
> su to the script's desired user and `pwd`?
I can su to httpd, I did it from within apache's root folder
(/usr/local/apache) and also in the apache/bin just in case, then I have no
problem cd-ing to / /srv /srv/sites and all the way to the final script
location of /srv/sites/p/paradox
I can't do ls in that location of course, because the r bit isn't set, but I
can do the pwd and get /srv/sites/p/paradox as it should be
The pwd command uses the system call getcwd() doesn't it?
now I can't su to root from httpd, that's a security restriction of the su
command on tru64 which only allows members of the system group to su root
but I can (with the password) su from httpd to the final user paradox in the
script location, the only thing that doesn't work there is the pwd which
gives the same error as suexec when trying to execute the script
shell-init: could not get current directory: getcwd: cannot access parent
directories: Permission denied
but those parent folders have the x bit set for other all the way to /
so what's holding it back then?
--
Didier Godefroy
mailto:dg@ulysium.net
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by André Malo <nd...@perlig.de>.
* <ld...@ulysium.net> wrote:
>> The script directory (httpd chdirs to it before invoking a CGI in general).
>> The user/group you have supplied via SuexecUserGroup in your httpd.conf.
>
> So at the moment it tries to get that current working directory, it's
> already in the script's location and setuid to the user to execute as...
yes. (or say, it should ;-)
>> Hmm. What are the rights of the script directory?
>
> / has r-x for other
> /srv as well
> /srv/sites has --x for other and is the document root specified for suexec
and for the user itself?
Are you manually able to switch to the directory as httpd user, su to root,
su to the script's desired user and `pwd`?
Strange at all ;-)
nd
--
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join #########################
[ $japh =~ /{(.)}/] -> [0] => map $_ -> () # André Malo #
=> @japh; # http://www.perlig.de/ #
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by ld...@ulysium.net.
> The script directory (httpd chdirs to it before invoking a CGI in general).
> The user/group you have supplied via SuexecUserGroup in your httpd.conf.
So at the moment it tries to get that current working directory, it's
already in the script's location and setuid to the user to execute as...
>
> Hmm. What are the rights of the script directory?
/ has r-x for other
/srv as well
/srv/sites has --x for other and is the document root specified for suexec
then in the case of the specific site I'm trying to test on:
/srv/sites/p --x for other
/srv/sites/p/paradox the same and is the script's location
I put a simple test script in that location, which works without suexec
I chowned it (the script) to the user/group for suexec to work with it
I should be able to chmod it to 550 or even 500 under suexec, but I left it
as 555 for now for testing.
The problem is at the moment it doesn't even get to try to execute the
script, it's not quite there yet.
I planned to put all the cgi folders in a structured way under /srv/sites,
which was given to suexec at compile time as being the docroot.
However, I place user accounts outside of that tree, only the cgi folders
for all sites will be there. I just point the apache config to their proper
folders and I symlink to the real cgi-bin from each user account to allow
them to place their scripts there.
Is there a better way? (not mixing it all together in one big mess)
--
Didier Godefroy
mailto:dg@ulysium.net
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by André Malo <nd...@perlig.de>.
* <ld...@ulysium.net> wrote:
> cannot get current working directory (Permission denied)
>
> which is what I suspected, but on what directory and as what user?
The script directory (httpd chdirs to it before invoking a CGI in general).
The user/group you have supplied via SuexecUserGroup in your httpd.conf.
> Obviously it's not trying this as root, but has it switched to the new user
> to run the cgi at that time or is it still httpd ???
nope, it's suexec.
Hmm. What are the rights of the script directory?
nd
--
s;.*;aaaaaoaaaoaaaaooooaaoaaaomaaaa:a:alataa:aaoat:a:a:a
maoaa:a:laoata:a:oia:a:o:a:m:a:o:alaoooat:aaool:aaoaa
matooololaaatoto:aaa:o:a:o:m;;s:\s:\::g;y;mailto:;
\40\51/\134\137|ndparker <nd...@perlig.de>;;print;
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by André Malo <nd...@perlig.de>.
* <ld...@ulysium.net> wrote:
>> search that text in support/suexec.c and replace the line
>>
>> log_err("cannot get current working directory\n");
>> with
>> log_err("cannot get current working directory (%s)\n", strerror(errno));
>>
>> recompile and look what it says.
>
> Can I recompile only suexec? It should be possible to do this without doing
> the whole thing over again.
If you have kept your source directory from the recent compilation - yes.
(cd support && make suexec, then copy suexec to your installation)
From the vanilla tarball, I think not
(at least /me had problems to do so :).
nd
--
die (eval q-qq[Just Another Perl Hacker
]
;-)
# André Malo, <http://pub.perlig.de/> #
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by ld...@ulysium.net.
> search that text in support/suexec.c and replace the line
>
> log_err("cannot get current working directory\n");
> with
> log_err("cannot get current working directory (%s)\n", strerror(errno));
>
> recompile and look what it says.
Ok, not being sure how to recompile only suexec without doing the whole
thing again, I tried this:
make suexec
in the support folder, and I guess that built a new suexec, so I put that in
its place and started apache again and the error now is:
cannot get current working directory (Permission denied)
which is what I suspected, but on what directory and as what user?
Obviously it's not trying this as root, but has it switched to the new user
to run the cgi at that time or is it still httpd ???
--
Didier Godefroy
mailto:dg@ulysium.net
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by ld...@ulysium.net.
> search that text in support/suexec.c and replace the line
>
> log_err("cannot get current working directory\n");
> with
> log_err("cannot get current working directory (%s)\n", strerror(errno));
>
> recompile and look what it says.
Can I recompile only suexec? It should be possible to do this without doing
the whole thing over again.
--
Didier Godefroy
mailto:dg@ulysium.net
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] small Suexec problem
Posted by André Malo <nd...@perlig.de>.
* <ld...@ulysium.net> wrote:
> the system is tru64 unix, apache 2.0.45
I've no experiences with true64, but a getcwd() failure may have several
reasons in general.
> What I get is an error in the suexec log that says:
>
> cannot get current working directory
You may try the following:
search that text in support/suexec.c and replace the line
log_err("cannot get current working directory\n");
with
log_err("cannot get current working directory (%s)\n", strerror(errno));
recompile and look what it says.
nd
--
>kann mir jemand sagen, was genau @-Domains sind?
Ein Mythos. Ein Werbetrick. Verarsche. Nenn es wie du willst...
-- Alexandra Buss und Björn Höhrmann in dciwam
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org