On Sat, 2013-07-27 at 08:44 +0100, Stephen Gran wrote: > This one time, at band camp, Sam Morris said: > > On Fri, 2013-07-26 at 19:39 +0100, Stephen Gran wrote: > > > This one time, at band camp, Sam Morris said: > > > > Therefore I don't see the use of having both options, unless some other > > > > software cares about the difference between the two values, > > > > > > They do mean something different: > > > > > > From the wikipedia page: > > > > > > "NP" or "!" or null - No password, the account has no password. > > > "LK" or "*" - the account is Locked, user will be unable to log-in > > > > > > There is a semantic difference between the two. ! in the field says > > > that authentication with a password should never succeed. * says that > > > login should never succeed, even if alternate forms of authentication > > > (such as ssh keys) are in use. The above chunk of code is correct if it > > > is in a password checking routine - both should return false for > > > authentication. > > > > See <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=219377>. It is > > possible to SSH in to a machine as an account with only * in its > > password field. In addition, shadow(5) doesn't draw any distinction > > between the two values: > > > > If the password field contains some string that is not a valid > > result of crypt(3), for instance ! or *, the user will not be > > able to use a unix password to log in (but the user may log in > > the system by other means). > > > > pam_unix's accounting code doesn't use the password field at all--only > > the additional fields in the shadow file. > > > > My gut feeling is that if there ever was a distinction between the two > > values, it is lost to history. Perhaps * used to be used before the > > advent of shadow files to indicate that the entire account was locked > > rather than just the password. I don't know, I wasn't around in those > > days. :) > > So, I think that maybe I'm confused - I am under the impression that > you started by saying that there is no useful difference between the > two states 'locked' and 'disabled'. I responded by saying there was. > In defense of your statement, you've pointed me to a bug report that > says that pam now looks elsewhere to distinguish between the two states, > and that it was a bug in shadow not to set that other flag, and that > that bug is now fixed.
Sorry, I meant to also draw your attention to the clone bug, <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389183#122>. The fix was reverted because, as it turns out, people were used to the old behaviour (that 'passwd -l' would lock the password, and not the entire account). (I think Nicolas made a couple of typos when composing that message, and sometimes said 'account' where he meant 'password', so read the bullet points carefully.) As an aside, I did some more searching and found that OpenSSH, if you disable PAM, will take ! to mean disable the entire account & deny access without attempting authentication. This can be seen at <http://sources.debian.net/src/openssh/1:6.2p2-6/auth.c#L134>. In fact, <http://sources.debian.net/src/openssh/1:6.2p2-6/configure.ac> reveals how OpenSSH interprets the password field on various UNIXes when PAM is disabled: Host OS String Mode Note ------------------------------------------------------------- HP-UX * exact IRIX *LK* exact GNU/kFreeBSD ! prefix GNU/kOpenSolaris ! prefix Linux ! prefix FreeBSD *LOCKED* prefix Solaris *LK* exact UnixWare/OpenUNIX *LK* exact Tru64 Unix NoLogin substring When OSF SIA disabled This information may be of some historical interest. It gives that Wikipedia page something to cite, at least. :) -- Sam Morris <https://robots.org.uk/> 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078
signature.asc
Description: This is a digitally signed message part
