FS#43480 - [filesystem] shadow - 'x' in encrypted password field

Attached to Project: Arch Linux
Opened by nfnty (nfnty) - Friday, 16 January 2015, 23:16 GMT
Last edited by Dave Reisner (falconindy) - Monday, 26 January 2015, 00:15 GMT
Task Type General Gripe
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Wouldn't it be better to have '!' instead of 'x' in the encrypted password field for all locked accounts? More consistent and properly documented.

I.e.:
bin:!:14871::::::

Not:
bin:x:14871::::::

Quote from shadow(5):
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).
This task depends upon

Closed by  Dave Reisner (falconindy)
Monday, 26 January 2015, 00:15 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Nothing to fix. An 'x' is as good as a '*' is as good as a '!', as described by the documentation.
Comment by Dave Reisner (falconindy) - Wednesday, 21 January 2015, 16:31 GMT
! and * might be documented examples, but it also clearly states that anything which is an invalid result of crypt(3) can be used. 'x' fits this criteria. Is there an actual problem here?
Comment by nfnty (nfnty) - Wednesday, 21 January 2015, 18:12 GMT
It took me quite some researching to figure out what 'x' meant. Stating that anything being an invalid result of crypt(3) is vague and not very helpful. Crypt(3) is very ambiguous on the matter and never mentions anything about 'invalid result'. Only the last part of crypt(3) mentions anything related to it, stating: "The characters in "salt" and "encrypted" are drawn from the set [a-zA-Z0-9./].". The examples given in shadow(5) are very easy to understand and do not require further researching on the internals of the crypt() function.

The only shadow users that have 'x' as their encrypted password is the default ones included from this package. All other users have '!' as their encrypted password if not set. Consistency would be great.
Comment by Dave Reisner (falconindy) - Monday, 26 January 2015, 00:14 GMT
An invalid return from crypt(3) is simply some output that can't possibly be the result of hashing a password. As such, *any* single character, or string with a non-hex digit fulfills this. If you're looking at details at this low level, I think it's easier to understand the concepts rather than the implementation. There's a number of tools which might write to /etc/whatever and I'm not going to be held responsible for making sure they're all doing the same thing. Currently, the userdb files included with filesystem all use 'x' to denote an invalid password. That's as much consistency as you're going to get out of me.

Loading...