svn commit: r365643 - head/bin/cp

[Rodney W. Grimes]

> On Thu, Sep 24, 2020 at 12:41 AM Stefan Esser <se at 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                                                 rgrimes at freebsd.org