What does it mean to have a '*' as the second field (with ':' delimiter) for a group record in /etc/group? There is also a user name with the same name as that group, being a member of it, also of group users. Exemple:

[...]
console:x:101:
razvan:*:1000:
dovecot:x:202:
dovenull:x:203:
[...]

Thanks anticipated!

Too my knowledge the x and * represent the same thing (although * is seen less often).

1 members found this post helpful.

Did some further digging and came up with this from the gshadow man page:The x can also be included in the above quote.

1 members found this post helpful.

Ok, thanks, but what does really mean by "to access the group"? Maybe some example...

This deals with adding a password to a group. I haven't come across this in real life in all the years I've been using Unix/Linux.

Have a look at these:
- A group password in Linux
- Managing Group Access

Thanks, i was just quite curious and intrigued about that mysterious star.

I have one group to which I've assigned a password. It's handy for when you want your user to be able to write to certain directories only when you explicitly allow it by logging into a group that you're not normally a member of.


As for the field in question.
In /etc/passwd, or /etc/group 'x' normally signifies that shadow files are being used and the real entry is in /etc/shadow, /etc/gshadow.

Within the shadow files

x signifies that you can't login with a password
* as above but also signifies that the user or group is a 'system' group (i.e. one that is necessary for correct system operation and shouldn't be removed)
! signifies that an account/group has been locked (it is usually followed by the password hash.

In practice there is little difference between 'x' and '*', it's just documentary.

BTW, for some reason slackware's /etc/gshadow file is missing the standard groups You can fix this by running the grpck command as root (though this will tag all the groups as 'x' rather than '*')

2 members found this post helpful.

Very interesting and complete explanations, thanks very much. Still the question that comes into my mind is: why is that group marked as system group, maybe because it was the first user group created, when creating first normal user, which has the same name as that group name, with User Manager (kuser)?

IMO All GUI admin tools should be stamped with "Here be DRAGONS!"

Best to avoid them and use the native tools: in this case useradd (or adduser for an easy life), groupadd, etc.

2 members found this post helpful.

i know, that was inherited from a more beginner level of SW user/admin.

I looked at the group man page to see how Linux may vary from UNIX regarding this file. I don't want to promote sloppy system administration practices but I found the comment in the group man page interesting.

Like GaZL I've found occasions (in a previous life) to set a group password. It appears to be a dying and forgotten practice.

Which comment? If you are talking about the password field being empty: Remember that the shadow suite is being used as well.

As mentioned in one of the links I posted previously: I'm guessing that this feature was introduced in a time that people were more trustworthy Better and more secure solutions are present/needed in this day and age.....

Hi druuna.

In my post I included the quoted "comment" I was referring to.

Perhaps "comment" was the wrong choice of words in my post. But when someone uses a phrase such as "No-one seems ..." I think of that more as a comment than a technical specification. Now, to be more precise, In my post I was referring to the "text" found in section 5 of the man pages for GROUP (the general topic of this thread). I quoted the text found in the BUGS section of that man page. Please type "man group" in a terminal on Slack64-14.0 with the proper path set up to see common man pages and you'll see it there. I don't know how else to explain what I thought was simply an interesting observation that I hadn't noticed before.

I was trying to reinforce your statement (that I quoted in my previous post) about your not needing the group password feature by my noting the lack of attention to even the maintenance the group file as mentioned in the man page reference. Based on your question I must not have done a very good job of communicating my thoughts in my previous post.

My simple previous post is not worth all the text I just now typed trying to explain it.

One can argue the point of what constitutes good security and whether "groups" are the proper way to implement a particular security requirement, but the author of the link you quoted may be missing the full picture of how groups are/were used in *NIX systems. A "group" has a shared responsibility/authority among its members.

I look at group membership and group passwords as just another option for controlling access, along with custom programs, multiple login accounts, and in more modern times, ACLs and sudo. You still have to know the password to change to password protected groups (unless Linux works differently) so it's not a completely trusting option. A group password can protect the system from an authorized user making mistakes or running an unknowingly destructive program, by not giving that authorized user the proper permissions unless needed for the operation. Similar to how sudo is used by many today. I got the impression that this principle of least privilege is the purpose to which GazL applies group passwords.

Group passwords are just a (now apparently forgotten) option, not a panacea.

1 members found this post helpful.

My use of group passwords is in order to follow the principle of least-privilege. I am the only one who will know the group's password, there will be no sharing and as such the auditing and accountability issues are not relevant. Use of a permanent secondary group would not achieve what I'm after (a temporary raise in privilege).

I'll have to look into 'sudo -g' and see if that would be an alternative approach but as auditing isn't a consideration for me there is little to be gained by complicating things.


Group passwords should not be avoided simply because dogma says they're bad. If they fit the situation and their weaknesses aren't relevant then I see no problem with using them.

edit:
@Tracy, Sorry I hadn't read your post before replying, looks like you understand me well.