Noriko Hosoi wrote:
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. But the dir name slapd-laputa2 is supposed to be
renamed to slapd-laputa2.removed. 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? Both scripts
are installed as root:
-rwxr-xr-x 1 root root 4372 Jul 31 13:02 lib/fedora-ds/cgi-bin/ds_create
-rwxr-xr-x 1 root root 9304 Jul 31 13:13 lib/fedora-ds/cgi-bin/ds_remove
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.
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.
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.
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(?)
See above. ds_remove is run as nobody, and ds_create as root.
Can ds_remove run as root as well?
We shouldn't need to do that. I think we should fix this with permissions.
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. We may want to adjust...
drwxr-x--- 2 nobody nobody 4096 Jul 31 13:05 slapd-laputa
drwx------ 2 nobody root 4096 Jul 31 13:09 slapd-laputa2
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.
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
Thanks,
--noriko