Attachment 160789 Details for Bug 251090 – email discussion with Rich

email discussion with Rich

ds_remove_problem.eml.html (text/html), 4.73 KB, created by Noriko Hosoi on 2007-08-07 01:21:02 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Noriko Hosoi

Created: 2007-08-07 01:21:02 UTC

Size: 4.73 KB

patch

obsolete

><html>
><head>
><title>Re: ds_remove problem</title>
><link rel="important stylesheet" href="chrome://messenger/skin/messageBody.css">
></head>
><body>
><table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part1"><tr><td>Subject: Re: ds_remove problem</td></tr><tr><td>From: Richard Megginson <rmeggins@redhat.com></td></tr><tr><td>Date: Wed, 01 Aug 2007 09:18:41 -0600</td></tr></table><table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part2"><tr><td>To: Noriko Hosoi <nhosoi@redhat.com></td></tr><tr><td>CC: Nathan Kinder <nkinder@redhat.com></td></tr></table> 
><div class="moz-text-flowed">Noriko Hosoi wrote:
> <blockquote type=cite>Hi Rich,
> 
> Nathan found if the DSes are installed as root and run as nobody, 
>removing sub DS reports this error in the admin-serv/errors log 
>(although the remove operation from the Console successfully finishes):
> [Tue Jul 31 13:19:31 2007] [error] [client 172.16.25.156] 
>(13)Permission denied: exec of 
>'/export/servers/ds72/lib/fedora-ds/cgi-bin/ds_remove' failed
> 
> The to-be-removed instance directory is left with no files in it:
> $ ls -l lib/fedora-ds/slapd-laputa2
> total 0
> And the config dir etc/fedora-ds/slapd-laputa2 with the cert files, 
>which is expected.&nbsp; But the dir name slapd-laputa2 is supposed to be 
>renamed to slapd-laputa2.removed.&nbsp; This is also failing due to the 
>permission problem.
> 
> I checked the ownership of the CGI scripts, ds_create runs as root, 
>but ds_remove does as nobody:
> [root@laputa ds72]# cat /tmp/id.ds_create.out
> uid=0(root) gid=0(root) 
>groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) 
>context=root:system_r:unconfined_t
> [root@laputa ds72]# cat /tmp/id.ds_remove.out
> uid=99(nobody) gid=99(nobody) groups=99(nobody) 
>context=root:system_r:unconfined_t
> 
> Do you happen to know why/how the difference is made?&nbsp; Both scripts 
>are installed as root:
> -rwxr-xr-x&nbsp; 1 root root 4372 Jul 31 13:02 lib/fedora-ds/cgi-bin/ds_create
> -rwxr-xr-x&nbsp; 1 root root 9304 Jul 31 13:13 lib/fedora-ds/cgi-bin/ds_remove
> </blockquote>The owner of the script itself doesn't matter.&nbsp; The only thing that 
>matters is what UID the script runs as.&nbsp; Almost every CGI is run as the 
>admin server user, which is by default "nobody".&nbsp; In order to use this 
>to also manage directory server instances, the directory server 
>instances must also be owned by and run as "nobody", or they must all 
>belong to the same group, and the directory server instances must be 
>owned by that group and have group permissions set.
> 
> However, there are a few CGIs which are executed as root - start, 
>restart, and ds_create.&nbsp; This is because these CGIs may have to start up 
>a server listening to a low port, so they must be run as root.
> 
> The admin server default user has changed because of the switch to 
>Apache.&nbsp; The NES admin server used to run as root and could do anything 
>to any file or directory.&nbsp; However, Apache does not like to run as root, 
>and will not run as root by default on linux systems because of the way 
>it is compiled.&nbsp; So Rob C. had to steal the mod_cgi module and create 
>the mod_restartd module which allows root execution of those 
>aforementioned CGIs.
> <blockquote type=cite>
> The output from id is captured at the top of the CGI execution (before 
>ds_create / ds_remove being called), so it'd be a passed identity 
>maybe from Console(?)
> </blockquote>See above.&nbsp; ds_remove is run as nobody, and ds_create as root.
> <blockquote type=cite>Can ds_remove run as root as well?
> </blockquote>We shouldn't need to do that.&nbsp; I think we should fix this with permissions.
> <blockquote type=cite>Or could there be any good way for ds_remove to remove the instance 
>directory?
> 
> And this is not an issue, but the Configuration DS instance dir 
>created by setup-ds-admin.pl is owned by nobody.nobody, while the sub 
>DS created via Console is owned by nobody.root.&nbsp; We may want to adjust...
> drwxr-x---&nbsp; 2 nobody nobody&nbsp;&nbsp;&nbsp; 4096 Jul 31 13:05 slapd-laputa
> drwx------&nbsp; 2 nobody root&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4096 Jul 31 13:09 slapd-laputa2
> </blockquote>You cannot remove a directory unless you have permissions in the parent 
>directory, because you have to "write" to the parent directory to remove 
>a child directory.&nbsp; So I'm not sure what the best approach is.
> 1) Make /etc/fedora-ds and libdir/fedora-ds owned or writable by nobody 
>- I think the safest way to do this would be to assign group ownership 
>to the parent directory
> 2) Just have ds_remove execute as root
> <blockquote type=cite>
> Thanks,
> --noriko
> 
> </blockquote>
> </div></body>
></html>

<html>
<head>
<title>Re: ds_remove problem</title>
<link rel="important stylesheet" href="chrome://messenger/skin/messageBody.css">
</head>
<body>
<table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part1"><tr><td><b>Subject: </b>Re: ds_remove problem</td></tr><tr><td><b>From: </b>Richard Megginson <rmeggins@redhat.com></td></tr><tr><td><b>Date: </b>Wed, 01 Aug 2007 09:18:41 -0600</td></tr></table><table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part2"><tr><td><b>To: </b>Noriko Hosoi <nhosoi@redhat.com></td></tr><tr><td><b>CC: </b>Nathan Kinder <nkinder@redhat.com></td></tr></table><br>
<div class="moz-text-flowed">Noriko Hosoi wrote:
<br><blockquote type=cite>Hi Rich,
<br>
<br>Nathan found if the DSes are installed as root and run as nobody, 
removing sub DS reports this error in the admin-serv/errors log 
(although the remove operation from the Console successfully finishes):
<br>[Tue Jul 31 13:19:31 2007] [error] [client 172.16.25.156] 
(13)Permission denied: exec of 
'/export/servers/ds72/lib/fedora-ds/cgi-bin/ds_remove' failed
<br>
<br>The to-be-removed instance directory is left with no files in it:
<br>$ ls -l lib/fedora-ds/slapd-laputa2
<br>total 0
<br>And the config dir etc/fedora-ds/slapd-laputa2 with the cert files, 
which is expected.&nbsp; But the dir name slapd-laputa2 is supposed to be 
renamed to slapd-laputa2.removed.&nbsp; This is also failing due to the 
permission problem.
<br>
<br>I checked the ownership of the CGI scripts, ds_create runs as root, 
but ds_remove does as nobody:
<br>[root@laputa ds72]# cat /tmp/id.ds_create.out
<br>uid=0(root) gid=0(root) 
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) 
context=root:system_r:unconfined_t
<br>[root@laputa ds72]# cat /tmp/id.ds_remove.out
<br>uid=99(nobody) gid=99(nobody) groups=99(nobody) 
context=root:system_r:unconfined_t
<br>
<br>Do you happen to know why/how the difference is made?&nbsp; Both scripts 
are installed as root:
<br>-rwxr-xr-x&nbsp; 1 root root 4372 Jul 31 13:02 lib/fedora-ds/cgi-bin/ds_create
<br>-rwxr-xr-x&nbsp; 1 root root 9304 Jul 31 13:13 lib/fedora-ds/cgi-bin/ds_remove
<br></blockquote>The owner of the script itself doesn't matter.&nbsp; The only thing that 
matters is what UID the script runs as.&nbsp; Almost every CGI is run as the 
admin server user, which is by default "nobody".&nbsp; In order to use this 
to also manage directory server instances, the directory server 
instances must also be owned by and run as "nobody", or they must all 
belong to the same group, and the directory server instances must be 
owned by that group and have group permissions set.
<br>
<br>However, there are a few CGIs which are executed as root - start, 
restart, and ds_create.&nbsp; This is because these CGIs may have to start up 
a server listening to a low port, so they must be run as root.
<br>
<br>The admin server default user has changed because of the switch to 
Apache.&nbsp; The NES admin server used to run as root and could do anything 
to any file or directory.&nbsp; However, Apache does not like to run as root, 
and will not run as root by default on linux systems because of the way 
it is compiled.&nbsp; So Rob C. had to steal the mod_cgi module and create 
the mod_restartd module which allows root execution of those 
aforementioned CGIs.
<br><blockquote type=cite>
<br>The output from id is captured at the top of the CGI execution (before 
ds_create / ds_remove being called), so it'd be a passed identity 
maybe from Console(?)
<br></blockquote>See above.&nbsp; ds_remove is run as nobody, and ds_create as root.
<br><blockquote type=cite>Can ds_remove run as root as well?
<br></blockquote>We shouldn't need to do that.&nbsp; I think we should fix this with permissions.
<br><blockquote type=cite>Or could there be any good way for ds_remove to remove the instance 
directory?
<br>
<br>And this is not an issue, but the Configuration DS instance dir 
created by setup-ds-admin.pl is owned by nobody.nobody, while the sub 
DS created via Console is owned by nobody.root.&nbsp; We may want to adjust...
<br>drwxr-x---&nbsp; 2 nobody nobody&nbsp;&nbsp;&nbsp; 4096 Jul 31 13:05 slapd-laputa
<br>drwx------&nbsp; 2 nobody root&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4096 Jul 31 13:09 slapd-laputa2
<br></blockquote>You cannot remove a directory unless you have permissions in the parent 
directory, because you have to "write" to the parent directory to remove 
a child directory.&nbsp; So I'm not sure what the best approach is.
<br>1) Make /etc/fedora-ds and libdir/fedora-ds owned or writable by nobody 
- I think the safest way to do this would be to assign group ownership 
to the parent directory
<br>2) Just have ds_remove execute as root
<br><blockquote type=cite>
<br>Thanks,
<br>--noriko
<br>
<br></blockquote>
<br></div></body>
</html>

Actions: View

Attachments on bug 251090: 160789 | 160834 | 160835 | 160872 | 208571 | 208641 | 208681