What is available at early userspace?
On Thu, 01 Mar 2007, Nikita V. Youshchenko wrote:
> Sorry Marco, but it is not valid to close a bug report that describes an
> existing issue only because you don't like the solution suggested by the
> submitter.
Agreed, actually. But this is bigger than udev, it probably belongs in
"general", and not just one or two packages.
> Udev startup script does operate in restricted environment, where not all
> system services are already up and running. And it should be written as
> such.
So far so good. Udev really will have to somehow know when it is being run
at coldplug and very early userspace setup, and use a subset of the scripts.
> For ages, there was an agreement related to non-local auth services, that
> everything that is referenced before network service is up, should be
> resolvable by local data. 'Resolvable' here means that the result (being
> it positive or negative) should be available locally, without attempts to
> request data from not-yet-available service.
So far so good. This is basic.
> And in the current situation, udev is *the* package that, by installing
> it's default configuration files, injects references to
> non-resolvable-locally users and groups into early stage of boot.
Wrong. Your expectations to what is allowed to be non-resolvable-locally
are not in sync with what Debian currently supports. Note: I am not telling
you your expectations are unreasonable, but that they are more than what we
can properly support right now. And this is NOT just a bug in udev.
With async userspace, and more imporantly, async userspace boot, we need to
have things properly setup much earlier because we don't (currently) really
know when yhey will be needed. Udev is just one of the things that are part
of it. Dependency-based booting is another one.
The bottom line is that, until we define *exactly* what early userspace can
and cannot do, so that we can implement async userspace a lot more sanely,
any system which cannot work standalone until network is up and running is
going to break. And udev cannot really be expected to do much more than
what it already does unless we define the early userspace.
> So a *fix* for this issue could be only inside udev package.
No. In fact, a proper fix needs to be Debian-wide, a number of packages may
need to be changed to do it right. Udev is probably one of them, but not
the only one.
> - if base-passwd will be used as workaround location, this will create a
> situation when changes to default udev configuration files, introducing
> references to new groups or removing references to old ones, will cause
> need of base-files update - which is increased complexity and will cause
> out-of-sync situations;
This will be fixed when we know what early userspace can and cannot do, and
thus udev will know to which groups it must restrict itself. And probably
some way to defer rules from running while in early userspace could be
implemented, as well.
Note that we may end up defining that early userspace must restrict itself
to *static* system users and groups. That likely will require an increase
in the number of static system users and groups.
> - workaround at libnss-* level is complex (see all that logic with files
> noting boot process etc), needed in any libnss-* that references network,
Whatever we do, there is no magic here. Important system resources (users
and groups) that are needed at early userspace must *NOT* depend on anything
that is not provided by the initrd (or the kernel itself plus the root
partition), and that's it. You can *override* them later, so that, e.g.,
you can add a lot more stuff to group "sound" when network comes up.
libnss-* modules that need something more than what the
kernel/initrd/intramfs/whatever provides must not be active until the
resources they need are available. This is probably a big bad bug on most
of the libnss-* modules and their packaging, or maybe we should be swapping
/etc/nsswitch.conf around during boot.
> and generally misplaced - because, unlike udev init script, nss is not a
> system designed for restricted environment, and it is not it's job to
It has to be designed to work on restricted environments, because it is
running as soon as anything linked to libc needs it. That doesn't mean we
are using it correctly.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: