Summary: | sys-apps/shadow: strange useradd behavior when not using -g | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Max Lorenz <meax> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | caster, jdaluz, jnewby, ks, pva, rockoo, wschlich |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
shadow-fix-useradd-usergroups.patch
shadow-fix-useradd-usergroups.patch |
Description
Max Lorenz
2006-04-03 16:57:48 UTC
(In reply to comment #0) > This is whith shadow-4.0.15: > (handbook example) > # useradd -m -G users,wheel -s /bin/bash larry -G are supplementary groups, primary group is specified with -g > Also it doesn't seem to honor the GROUP setting in /etc/default/useradd: > # grep GROUP /etc/default/useradd > GROUP=100 seems true here (4.0.14-r1), suspected USERGROUPS_ENAB setting from /etc/login.defs also doesn't have any effect on this. Created attachment 84179 [details, diff]
shadow-fix-useradd-usergroups.patch
this should fix the issue i think
(In reply to comment #2) > shadow-fix-useradd-usergroups.patch > this should fix the issue i think This patch fixes the issue only if USERGROUPS_ENAB=no. But if it set to 'yes' I have the same result: theor home # useradd test theor home # id test uid=1007(test) gid=1007(test) groups=1007(test) Useradd still creates group 'test' instead of use the value from /etc/default/useradd: GROUP=100 But may be that is the right behaviour because it's really not clear for me what does this mean: # Enable setting of the umask group bits to be the same as owner bits # (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is # the same as gid, and username is the same as the primary group name. As I understand the previous sentense, USERGROUPS_ENAB should affect umask, but not useradd. > This patch fixes the issue only if USERGROUPS_ENAB=no. But if it set to 'yes'
> I have the same result:
that's the entire point ... the behavior you're seeing now is not a bug imo, but proper behavior
if you dont want user groups, disable USERGROPUS_ENAB
i'm still waiting for feedback from upstream on the issue though
This is pretty annoying. With which version of shadow has that behaviour been introduced? (In reply to comment #5) > This is pretty annoying. > With which version of shadow has that behaviour been introduced? We just realized this problem today. For us, this was introduced when we upgraded from 4.0.7-r4 to 4.0.14-r1. In 4.0.7-r4 useradd correctly used the default group setting in /etc/defaults/useradd. I just upgraded to 4.0.15-r2 to see if anything has been fixed, and it is still broken. Created attachment 88913 [details, diff]
shadow-fix-useradd-usergroups.patch
more fixes
ok, this should be fixed in shadow-4.0.16-r1 we're still hashing out the final details upstream but at least our shadow wont be completely screwed up in the meantime :) I'm running shadow 4.0.17-r1 and have this same issue (pointed out to me by user Paapaa on the forums). Is this a regression, or per comment #8 have discussions with upstream resulted in this change being considered correct behavior? |