Simple & quick: why does /dev/console reset?

[jmb]

If the perms for /dev/console are changed away from world-writeable, they get reset by the system during reboot. I think this is true for other Unix platforms also. So why does this come up as a security concern, if the manufacturers default this setting to world-writeable? Is the only way to change it putting a script into startup?

[Steven E. Protter]

Its a security concern because a non-root user could conceivably get root access by accessing the file. I can't/won't explain how.

The system sets it to world write access so that processes that need to write to it can do so. In startup if you fire up oracle you do this with a su - c "oracle command" Thats a non-root user, but messages from that process need to go to the console.

Hope this doesn't muddle it up.

SEP

[A. Clay Stephenson]

The console (and especially for legacy programs) is sort of a dumping ground for error messages. It is common for daemons to simply write to /dev/console. Being able to write to /dev/console is really no big deal. About the worst that could happen is a spurious "Login/passwd" message could be written on the console and an unwary user might respond. However, for any real damage to be done, the process would need to be able to read from /dev/console --- it's the non-root read permissions that are dangerous.