On 9/17/06, Alex Merry <[EMAIL PROTECTED]> wrote:
On Sunday 17 September 2006 21:57, Bryan Kadzban wrote:
> I don't get any errors that would seem to indicate it requires a user
> or group named "nobody". Now yes, in the sources it does try to drop
> privileges by first looking up the "nobody" user in /etc/passwd, then
> dropping all supplementary groups, then setting the primary group to
> the GID of nobody, then setting the UID to the UID of nobody. And if
> one of those fails, it prints a message. But if the lookup
> (getpwnam) fails, it doesn't print or log anything, and when you
> don't have a nobody user, the lookup is what's going to fail.
>
> Unless this was different in udev-097? What message are you seeing?
It was different. The getpwnam call was introduced in 098 (see my other
post). Before that it unconditionally tried to become "nobody:nogroup".
It definitely prints errors without the nobody:nogroup around for
udev-097. We can probably ignore the error if udev is going to be
updated soon. Here's the output during boot:
vol_id[1075]: lookup_user: error resolving user 'nobody': Success
vol_id[1075]: lookup_group: error resolving group 'nogroup' Success
...
Repeated a few more times. I'd prefer to install the unprivelaged
user/group in LFS despite the fact the you say it will move on if it
can't drop privileges. This issue should probably be tied to the udev
version update. I'll open a ticket about it. If you want to tackle it,
go for it.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
