On Tue, Sep 02, 2003 at 12:37:21PM -0700, Ed Alley wrote: > > > 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: > >> > >> crw------- 1 root wheel 2, 2 Sep 2 11:20 /dev/null > > > 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. > > Sorry, I didn't mention that I tried setting flags on /dev/null: > > chflags schg /dev/null > > What happens is that sendmail complains that it can't open /dev/null. > > 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 -- 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
Description: PGP signature