As anyone who reads cvs-all (or Mark Johnston's wonderful summaries thereof) will know, I recently added logging into nologin(8): Instead of simply printing an error message, it now (via syslog) records the refused login attempt. For security reasons, nologin(8) must be statically linked; as a result, adding logging has increased the binary size by slightly over 100K (on i386). For historical reasons (which is to say, "nobody seems to know why"), nologin is located in /sbin, which means that this has a non-trivial effect upon the space used on the root partition. Some people are unhappy about this. I can see a number of possible options; I'd like to hear opinions on which would be the best. 1. Leave everything as it is right now. Pro: Simplicity; logging is useful. Con: Bloating of the root filesystem. 2. Revert to the previous situation, without any logging. Pro: Saves space on the root filesystem Con: Logging would be useful. 3. Move nologin(8) to /usr/sbin Pro: There is no reason for nologin(8) to be in /sbin, since it isn't needed in single-user mode; this would retain logging without bloating the root fs. Con: Everyone who has hard-coded /sbin/nologin would have to fix their code. 4. Move nologin(8) to /usr/sbin, leave a symlink behind. Pro: Any time that users would be trying to log in, /usr/sbin should be mounted, so this should give the desired behaviour without bloating /. Con: [ -f /sbin/nologin ] would fail, which might be problematic. 5. Move nologin(8) to /usr/sbin, and leave /sbin/nologin behind with logging disabled. Pro: System administrators who want to record logins refused by nologin can do so easily; anyone who doesn't need this will see the same behaviour as in the past. Con: Having two different binaries with the same name in the path might cause problems. 6. Get rid of nologin(8) completely, and tell people to install Wes Peters' sysutils/no-login port instead. Pro: It would save space on the root filesystem, and even reduce buildworld time by somewhere around half a second. :) Colin PercivalReceived on Mon Feb 23 2004 - 08:45:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:44 UTC