Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Nov 2002 21:27:16 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        tjr@FreeBSD.ORG
Cc:        kris@obsecurity.org, current@FreeBSD.ORG
Subject:   Re: Device permissions with DEVFS
Message-ID:  <20021119.212716.23011355.imp@bsdimp.com>
In-Reply-To: <20021119174652.A74461@dilbert.robbins.dropbear.id.au>
References:  <20021119050304.GA2608@rot13.obsecurity.org> <20021119174652.A74461@dilbert.robbins.dropbear.id.au>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20021119174652.A74461@dilbert.robbins.dropbear.id.au>
            Tim Robbins <tjr@FreeBSD.ORG> writes:
: I'm glad you brought this up... I'd like to see /dev/devctl made mode 600
: instead of 644 because it does not look very robust and because only one
: devctl can be open at a time.

644 is the right permissions to use.  I'd strongly oppose any attempt
to change that.  devctl will likely grow the ability to be cloned
soon.

: The two other security/reliability bugs I can see are that the async
: (ioctl FIOASYNC) and non-blocking (ioctl FIONBIO) flags are not cleared
: between when one process closes the device and another opens it. Leaving
: the non-blocking flag set confuses devd(8) causing it to exit immediately.

Good point.  that's good.

: It looks like there are some races involving devsoftc, the softc mutex
: should probably be locked around checking the inuse flag in devopen(),
: around clearing it in devclose(), around setting async and async_td in
: devioctl() FIOASYNC case, around checking inuse and async_td in
: devaddq().

I don't think that these are an issue.  You never need to lock a
mutext just to check a bit.  I'm not sure that there's a real race
here that matters if you lose or win.  Those are atomic operations...

Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021119.212716.23011355.imp>