Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 160789 Details for
Bug 251090
ds_remove cannot remove/rename directories
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
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:
email discussion with Rich
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><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. But the dir name slapd-laputa2 is supposed to be >renamed to slapd-laputa2.removed. 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? Both scripts >are installed as root: ><br>-rwxr-xr-x 1 root root 4372 Jul 31 13:02 lib/fedora-ds/cgi-bin/ds_create ><br>-rwxr-xr-x 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. The only thing that >matters is what UID the script runs as. Almost every CGI is run as the >admin server user, which is by default "nobody". 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. 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. The NES admin server used to run as root and could do anything >to any file or directory. 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. 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. 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. 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. We may want to adjust... ><br>drwxr-x--- 2 nobody nobody 4096 Jul 31 13:05 slapd-laputa ><br>drwx------ 2 nobody root 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. 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>
<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. But the dir name slapd-laputa2 is supposed to be renamed to slapd-laputa2.removed. 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? Both scripts are installed as root: <br>-rwxr-xr-x 1 root root 4372 Jul 31 13:02 lib/fedora-ds/cgi-bin/ds_create <br>-rwxr-xr-x 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. The only thing that matters is what UID the script runs as. Almost every CGI is run as the admin server user, which is by default "nobody". 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. 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. The NES admin server used to run as root and could do anything to any file or directory. 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. 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. 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. 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. We may want to adjust... <br>drwxr-x--- 2 nobody nobody 4096 Jul 31 13:05 slapd-laputa <br>drwx------ 2 nobody root 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. 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>
View Attachment As Raw
Actions:
View
Attachments on
bug 251090
: 160789 |
160834
|
160835
|
160872
|
208571
|
208641
|
208681