As a follow-up of bug 668158 I'd like to mention that I think enewuser behaves not as intended when creating new users home directory. enewuser calls useradd with -r, which means the home directory will not be created by useradd. Therefore the following gets executed in enewuser() if the home dir was not created: > mkdir -p "${ROOT}/${ehome}" > chown "${euser}" "${ROOT}/${ehome}" > chmod 755 "${ROOT}/${ehome}" chown does not add a :<group> here. I think that's why the home directory is created with <user>:root instead of <user>:<group>. A possible solution could be either adding -m to adduser or ${defgroup} to chown.
(In reply to Christian Buchinger from comment #0) > Therefore the following gets executed in enewuser() if the home dir was not > created: > > > mkdir -p "${ROOT}/${ehome}" > > chown "${euser}" "${ROOT}/${ehome}" > > chmod 755 "${ROOT}/${ehome}" > > chown does not add a :<group> here. I think that's why the home directory is > created with <user>:root instead of <user>:<group>. Well, mkdir is running as root, therefore the folder will be created with root's default permission. When calling chown we only specify user, therefore we don't tell chown that we want to change group as well. > A possible solution could be either adding -m to adduser or ${defgroup} to > chown. Right, we would need to add group to that call. On first view it looks like you are right and we could use $defgroup but I need more testing/thinking about this. But due to bug 668158 and friends, we wouldn't see any outcome of that change at the moment. So I am also not sure if we should mark this bug to depend on the portage change and only consider eclass change once portage was fixed.
(In reply to Thomas Deutschmann from comment #1) > [...] > Right, we would need to add group to that call. On first view it looks like > you are right and we could use $defgroup but I need more testing/thinking > about this. Yes, I guess we'd need to catch case when groups are not set at least. > But due to bug 668158 and friends, we wouldn't see any outcome of that > change at the moment. So I am also not sure if we should mark this bug to > depend on the portage change and only consider eclass change once portage > was fixed. I see it as an isolated bug for enewuser(), yes. Just added your bug as reference because I found quite some ebuilds in the tree with the same pattern (enewgroup; enewuser with homedir; fowners for homedir;) but I didn't meant to depend on it. The other problem (changes from src_install not being merged over existing stuff) still exists. (E.g. setting permissions.)
This sounds like exactly the same bug which led to me documenting this behaviour at bug 614396 comment 7. They decided that the way to fix that bug was to fix the permissions afterwards... it didn't sound right to me at the time but I'm not a Gentoo dev, so. It'd be nice to have this bug fixed once and for all!
user.eclass has been removed from the gentoo repo.
