[incorrectly assigned to rootfiles by ignorance of component and inflexibility of 'Component Text' field, please reassign if nccy] Doing 'chattr +i /' has an odd, unwelcome result: 1. breaks logging after next 'init.d/syslogd restart' 2. results in minilogd listening to '/dev/log' and swelling pregnant buffer "forever" (I didn't check this, but) if minilogd has a mem ulimit or buff size limit it may later die with logging still broken... but if not, the stored syslog buffer may eventually swab swap and panic the system (?) --- On startup, minilogd does an access('/') -- perhaps to decide whether the system is running at a boot step prior to the r/w mounting of '/' If '/' is not writeable for any reason, minilogd then directly proceeds to unlink and link /dev/log, and parks waiting for messages. [[[ Perhaps it base that assumption directly on access('/dev/log') instead...? If the system has not yet mounted root-fsys rw the socket would also fail the test. There may exist a scenario where a attacker script may "chattr +i /dev/log; killall syslogd" ... I leave the task of effect and possible check & countermeasure to more devious people with better brains... ]]] >>> In this instance it also does not check to see if syslog is already running. I set immutable on '/', and some other directories and files, which seemed a prudent precaution to take to thwart possible script kiddies running rootscripts that are not chattr-aware... or perhaps protect against the ability to trick a suid program into writing as root on/into a critical file or directory... though I admit ALSO as slippery-finger insurance for crosseyed su infested operators ;) ... Upon next syslogd restart, logging stops and does not resume: as part of the deep '/etc/rc.d/init.d/syslog restart' sequence, initlog runs minilogd which -- upon the fail of access('/') -- diverges from its usual course... unlinks /dev/log out from under the running syslogd, which is still ready to log something but does not notice that it is now listening on an orphaned inode... minilogd parks and sucks /dev/log for all eternity...
This is *not* a security bug. If an attacker gets enough privelege to modify /dev/log, he can do so many other things that it's rather pointless to worry about this particular case. Still, the 'start daemon' algorithm does need fixed; we'll look into it.
This will be fixed in initscripts-5.45-1.