Re: no deprecation of /usr as a standalone filesystem
Marco d'Itri wrote:
> On Jun 02, "Giacomo A. Catenazzi" <firstname.lastname@example.org> wrote:
>> - there is still a close windows in initram, and possibility
>> at early rc scripts.
>> - /var is still not mounted, so programs could not write they status, nor
>> log failures
> So programs which have such requirements need to take care of waiting
> long enough. e.g. the ifupdown wrapper script waits for /dev/log to
>> - care about security implication: user that triggers events before system
>> is fully up (e.g. busy resources)
> I see no security implications.
Wrong udev script could make busy resources, mounting point, ...
which cause an unexpected execution path (when there are bugs on
We cannot log problems, and we cannot reproduce errors, because
it is difficult to plug again devices at the exact same time
of previous run.
Some newbies (and others) will have wrong permissions in udev configuration
(google for udev rules, and you will see ugly and unsecure udev rules).
Such rules are not done by you or Debian, but we cannot ignore that people
do thing wrongly and publish it.
So the security rule I recently see in a RFC (which disabled some
cryptography algorithms): "seldom run paths should be considered
>> - and I think other usual system assumption are not fulfilled, so
>> maintainers should be trained on what they could assume on udev sequence.
> Maintainers who have doubts can ask for help here or by private mail.
>> For these reasons, I think only few events (explicitly ack by maintainers)
>> should be handled by early boot, and the rest run later (udev events are
>> already asynchronous by definition).
> There is no need for this.
More I think about the specific issue, the more I think we should not
accept hotplug before very late boot process: kernel and boot people
hate asynchronous boot process, because it boot process has
bugs, but it is very difficult to track such bugs.
With udev we have the same cases: how many of us test every device with
Do we really need to handle such hotplugs? We could require that
all boot hardwares must be available short after boot loader. The
later plugged hardware will be shown only later, when the system
in up. I see no disadvantage, and make thing easier, more
testable (and I think also more secure).
But nobody commented with the orthogonal question:
could we handle /usr specially and mount at the beginning?
We eventually lose networked /usr, but we can still use
plain non-crypted read-only /usr as an other partition.