> On Thu, Sep 24, 2020 at 12:41 AM Stefan Esser <s...@freebsd.org> wrote:
>
> > Am 23.09.20 um 19:23 schrieb Warner Losh> But for this issue, we're not
> > mounting devfs early enough. We should
> > > fix that. Removing /dev/null from the boot process likely is never going
> > > to happen because we use it all over the place to discard output...
> > > There's ~200 instances of it in the boot rc scripts, so getting rid of
> > > it there would also be quite the effort, with the same question.
> >
> > Removal of /dev/null from rc.d scripts should be quite simple,
> > since most cases could just use ">-" (close file descriptor)
> > instead. Other usage could be substituted with ":>" followed
> > by chown.
> >
>
> So closing fd1 and fd2 doesn't cause them to be available for these
> programs to get as an fd on open, causing other issues?
>
> But >- isn't documented in sh(1) as doing the close thing. On a whim I did
> the following:
> $ echo fred >-
> $ ls -last ./-
> 4 -rw-r--r-- 1 imp imp 5 Sep 24 00:50 ./-
> $ cat ./-
> fred
> $
> which suggests maybe you now have a lot of files named - instead...
>
>
> > I'd be willing to generate patches for review, if there is any
> > chance such a change might be accepted into -CURRENT.
> >
> > I could not find any use of /dev/zero,
>
>
> Yea, I'd thought we used it in libc, but I can't find any evidence of that
> with grep now that I've gone looking for it. For get that specific one :)
>
>
> > but e.g. rc.d/syscons
> > uses ${kbddev} (i.e. /dev/ttyv0) and rc.d/zvol performs swapon
> > on /dev/zvol/${name}, rc.d/random uses /dev/random and so on.
> >
>
> So those interactions should be disaled by rc variables... Or we should be
> failing the operation...
I believe there are several cases in the rc scripts of failure
to fail, and I have experinced at least one that left a firewall
wide open that I would of just rather had it fail and drop to
single user. I have repeatedly heard the argument, "but you
want it to continue so you can get into it" NO, not if that
failure leads to a security risk.
Most modern systems have out of band management so the story
of "but you cant get to the system if it stops" no longer
holds water with me.
I have worked around these locally.
>
> > But those further references to /dev nodes will in general be
> > NOPs if /dev is not available (some test for existence of the
> > node they rely on, other just fail trying to access them, but
> > without negative effect on going multi-user).
> >
>
> Yea, that's more minor, but if /dev/ isn't there, they likely should fail,
> or shouldn't proceed... But in a way that allows the rest of the rc scripts
> to continue...
This notion that "must boot at all cost" leads to security risks.
> Warner
--
Rod Grimes rgri...@freebsd.org
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
