Date: Tue, 2 Sep 2003 21:34:35 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Ed Alley <alley1@llnl.gov> Cc: freebsd-questions@freebsd.org Subject: Re: your mail Message-ID: <20030902203435.GA14407@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <200309021937.h82JbLY3011572@jordan.llnl.gov> References: <200309021937.h82JbLY3011572@jordan.llnl.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Sep 02, 2003 at 12:37:21PM -0700, Ed Alley wrote:
>=20
> > On Tue, 2003-09-02 at 14:32, Ed Alley wrote:
> >> I'm running FreeBSD-4.8. Sometimes the file permissions for /dev/null =
get
> >> mysteriously changed by some unknown process to:
> >>=20
> >> crw------- 1 root wheel 2, 2 Sep 2 11:20 /dev/null
>=20
> > On Tue, 2003-09-02 Adam McLaurin wrote:
> > That's very strange indeed. Have you tried using chflags to prevent the
> > permissions from being changed? This should do the trick, albeit a dirty
> > hack.
>=20
> Sorry, I didn't mention that I tried setting flags on /dev/null:
>=20
> chflags schg /dev/null
>=20
> What happens is that sendmail complains that it can't open /dev/null.
>=20
> Hey! I just realized that this may be a clue! Does sendmail fiddle with
> /dev/null? What happens if sendmail tries to lock /dev/null after it
> opens it? Does schg prevent fcntl from locking /dev/null, if that is
> what sendmail uses?
Lock it why? There's no point locking the null device -- it's not like
it has contents that can be changed out from underneath a process...
Besides, a large number of processes tend to have open descriptors on
/dev/null -- any well behaved daemon process will close its stdin,
stdout and stderr and re-open them on /dev/null as part of the
standard setup for becoming a daemon. See daemon(3). Getting a
mandatory exclusive lock on /dev/null early in the boot process would
be a very effective way to cripple a system...
If you want to see what processes have an open file descriptor on
/dev/null, try:
% fstat -f /dev | grep ' null '
There will be more than you expect. As for tracking down what process
has mucked up the permissions on the device: that's going to be quite
laborious. You'll probably have to do something horribly tedious like
not running each process (that uses /dev/null) in turn, and see if you
can identify when the chmod(2) doesn't happen. It would have to be a
root-owned process to change the permissions on the device, which will
cut the list down a bit. Remember though that many daemon processes
will start as UID root in order to bind low-numbered network ports,
and then change their UID to something less privileged as a security
measure.
Cheers,
Matthew=09
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--6TrnltStXW4iwmi0
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQE/VP7bdtESqEQa7a0RAj+RAJ94malpNZpjWn/LOvW0yHqdbjEL0gCfSSIJ
ctyV4vTLiEeMOu30bNqiDQ8=
=aHXR
-----END PGP SIGNATURE-----
--6TrnltStXW4iwmi0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030902203435.GA14407>