There was a short discussion on irc later:
(12:49:06) doener: daniel_hozac: hm, doesn't make that patch the assumption
that you have already chroot'ed?
(12:50:50) daniel_hozac: doener: the chroot happens before the uid is used.
(12:51:21) daniel_hozac: but yeah, for when you use --uid and not --chroot, it
won't do the right thing.
(12:54:03) doener: ah, right the chroot stuff is in there... but maybe the
name to uid resolution could be done by some other tool in the chain and have
only "vserver" accept names, while vcontext just gets some checks to ensure
that the uid is a valid number
(12:55:09) doener: the other tool could receive the path to the vserver (or
look it up) and use fgetpwent
(12:55:20) daniel_hozac: the resolution would have to happen after vcontext.
(12:57:14) doener: why?
(12:59:44) doener:
http://www.13thfloor.at/~doener/vserver/tools/vexec-0.03.c -- resolution
happens first
(13:05:19) daniel_hozac: i guess the optimal solution would be one that
executes id inside the vserver.
(13:07:54) daniel_hozac: as that would work even for nss_ldap and such.
(13:16:26) DavidS: daniel_hozac: while i agree, that the resolution should
happen within the context, I can't image how that should work in a generic
fashin (does id/getent exist everywhere?)
(13:17:34) daniel_hozac: right, which is why my patch does it sort-of-inside.
(13:22:04) DavidS: i would have expected suexec to use "su" from the
vserver ...
(13:25:21) daniel_hozac: well, if you can't expect id to be present, you can't
expect su to be present either :)
(13:31:58) DavidS: daniel_hozac: touche :)
(13:32:44) DavidS: then it should probably be something in the apps/ config?
how-to-{change,map}-uid ?
(13:32:56) DavidS: with id/su as good defaults
(13:35:40) daniel_hozac: well, you can already use vserver ... exec su ...
(13:36:10) daniel_hozac: vserver ... suexec implies it's something that the
utils themselves do.
(13:36:50) DavidS: then you can't ever resolve a _name_
(13:37:06) daniel_hozac: hmm?
(13:37:06) shedi left the room (quit: Quit: Leaving).
(13:38:24) DavidS: where is the difference between using lib_nss,
reading /etc/passwd or using id/su/getent?
(13:38:38) DavidS: (everything from the vserver of course)
(13:39:18) DavidS: resolving a name within the vserver without using
information (executable or otherwise) from the vserver is impossible ...
(13:39:33) daniel_hozac: we can't do the first, parsing /etc/passwd
and /etc/group manually when there are already functions to do so invokes the
lazyness in me, and the third, well, you can already do that.
(13:40:04) daniel_hozac: my patch will use getpwent and initgroups for
usernames.
(13:42:29) DavidS: i've seen it .. ah, that was the dietlibc ifdef ...
preventing to use glibc/nss
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
