Today i was going through some of security guides written on linux .
Under shadow file security following points were mentioned.
1)The encrypted password stored under /etc/shadow file should have more than 14-25 characters.
2)Usernames in shadow file must satisfy to all the same rules as usernames in /etc/passwd.
3)password for application Username should display * if username is not locked.
4)If a user is locked it should be displayed as ! as the first character in second field of shadow file.
Confusion for point 1 and 2:
Now i m confused as why the encrypted password should be more than 14-25 characters.
Also what rules to satisfy How to check it?
Confusion for point 3 and 4:
There are lot of users with * as second field i guess they are not locked but according to 4th point there are lot of users with ! as first characters.
How would i check whether they are actually locked or not.
I m posting the output of /etc/shadow and /etc/passwd files for the account.
To check the status of an account you can issue following on Linux:
$> passwd -S sshd
sshd L 05/30/2007 0 99999 7 -1
From the man page of passwd:
-S, --status
Display account status information. The status information consists of 7 fields. The first field is the users login name. The second
field indicates if the user account has a locked password (L), has no password (NP), or has a usable password (P). The third field gives
the date of the last password change. The next four fields are the minimum age, maximum age, warning period, and inactivity period for the
password. These ages are expressed in days.
About the rules with the 14-25 characters for password length I would not worry since the binaries and libraries dealing with that usually work as intended.
Also something from the man page of shadow that might help:
encrypted password
Refer to crypt(3) for details on how this string is interpreted.
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 field may be empty, in which case no passwords are required to authenticate as the specified login name. However, some applications
which read the /etc/shadow file may decide not to permit any access at all if the password field is empty.
A password field which starts with a exclamation mark means that the password is locked. The remaining characters on the line represent
the password field before the password was locked.
Into a locked account can't be logged in, not by any other means - that's why it is locked. Even if you try to su - from root to the locked account, this will not be possible to access it (try it out).
Maybe I should read what I copy and paste to it's full length. I do not know other means they talk about or at least did not try any out - maybe another member of the forum can give you the answer or you just try out yourself some available to you.
Maybe using PAM and bypassing normal Unix login methods, idk.
To check the maximal value of a gid, I guess you take a look into your distributions header files in /usr/include (I checked on a Debian Linux):
I am not totally sure but I think that is what defines the max for the gid in the system. On a 32-bit system this would 2^32-1 ie. 4294967295 afaik.
Just out of curiosity - why do you need to know that?
This was no answer to my question why you are interessted in it. The update where you ask if I still think the gid is an unsigned integer does not show in any way in my eyes, why it shouldn't be.
Anyways, another approach that might get closer to your distribution and might be a better way
man group -> SEE ALSO getgrent(3)
man 3 getgrent -> pointing to grp.h and mentions a struct containing "gid_t gr_gid;"
Checking /usr/include/grp.h with vi shows "typedef __gid_t gid_t;". Before that line, there is 3 includes of other header files: #include <features.h>, #include <bits/types.h> and #include <stddef.h>, where only bits/types.h contains the definition I already mentioned and whatever will pointed at in your distribution.
Yes, I still think the gid is unsignend int and still see not why it is not.
Maybe someone else can kindly approve or disapprove this as I'd like to know if I am wrong.