enewuser: home beloning $user:root inset of $user:$group
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
is it intentional behavior, that home directories created by enewuser
belong to $user:root (or pwd group) instead of $user:$group ?
I recently set net-misc/minidlna to run as non-root and ended up with
minidlna:minidlna, see [1] for implementation details (and my
workaround) and [2,3] for the discussion leading to the situation.
p.s. I aware that chown/chmod and missing ${EPREFIX} makes this a bad
hack and fails on Prefix.
enewuser: home beloning $user:root inset of $user:$group
On Fri, Jul 20, 2012 at 11:32 AM, Michael Weber <xmw@gentoo.org> wrote:
> is it intentional behavior, that home directories created by enewuser
> belong to $user:root (or pwd group) instead of $user:$group ?
This seems like the result of a hasty bugfix to me:
https://bugs.gentoo.org/23627
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/eutils.eclass?r1=1.36&r2=1.37
Wrong group ownership shouldn't matter much, since ebuilds should
probably explicitly set home directory ownership / permissions with
fowners / fperms anyway (in src_install()). However, that doesn't work
due to:
https://bugs.gentoo.org/396153
Having a switch for enewuser to skip creating home directory would
solve the issue for majority of usecases, but a request I opened was
resolved as a duplicate of the bug above (which I don't expect to be
resolved anytime soon):
https://bugs.gentoo.org/395961
enewuser: home beloning $user:root inset of $user:$group
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 20/07/12 06:18 AM, Maxim Kammerer wrote:
> On Fri, Jul 20, 2012 at 11:32 AM, Michael Weber <xmw@gentoo.org>
> wrote:
>> is it intentional behavior, that home directories created by
>> enewuser belong to $user:root (or pwd group) instead of
>> $user:$group ?
>
> This seems like the result of a hasty bugfix to me:
> https://bugs.gentoo.org/23627
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/eutils.eclass?r1=1.36&r2=1.37
>
> Wrong group ownership shouldn't matter much, since ebuilds should
> probably explicitly set home directory ownership / permissions
> with fowners / fperms anyway (in src_install()). However, that
> doesn't work due to: https://bugs.gentoo.org/396153
>
> Having a switch for enewuser to skip creating home directory would
> solve the issue for majority of usecases, but a request I opened
> was resolved as a duplicate of the bug above (which I don't expect
> to be resolved anytime soon): https://bugs.gentoo.org/395961
>
enewuser won't create a home directory if you don't specify one (ie
it's set to /dev/null or it's unset). Also, you can use 'esethome' to
set the home directory to an existing directory. With both of these
options I don't think that a --do-not-create-homedir option is necessary.
enewuser: home beloning $user:root inset of $user:$group
On Fri, Jul 20, 2012 at 6:23 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> enewuser won't create a home directory if you don't specify one (ie
> it's set to /dev/null or it's unset). Also, you can use 'esethome' to
> set the home directory to an existing directory. With both of these
> options I don't think that a --do-not-create-homedir option is necessary.
Well, with this approach there will now be three separate code blocks,
just to create user's home directory: enewuser in pkg_preinst(),
fperms / fowners in src_install(), and esethome in pkg_postinst().
Changing permissions as suggested by Kevin Pyle [1] looks more
attractive then, since everything is in one code block. Moreover, if
you want to keep the same semantics with esethome (only set the home
directory when the user is created), you will need to keep a variable
across ebuild phases. Also, it looks like pkg_postinst() is on the way
out [2]. All-in-all, I think that a --do-not-create-homedir (or a
shorter equivalent) is a good idea.
enewuser: home beloning $user:root inset of $user:$group
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 07/20/2012 06:44 PM, Maxim Kammerer wrote:
> I think that a --do-not-create-homedir (or a shorter equivalent) is
> a good idea.
Yeah, just allow optional arguments to useradd like (useradd --help)
-m, --create-home create the user's home directory
-M, --no-create-home do not create the user's home directory
I would prefer an behavior similar to regular `useradd -m -g $group`
calls.
- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
enewuser: home beloning $user:root inset of $user:$group
On Sun, Jul 22, 2012 at 4:22 AM, Michael Weber <xmw@gentoo.org> wrote:
> Yeah, just allow optional arguments to useradd like (useradd --help)
> -m, --create-home create the user's home directory
> -M, --no-create-home do not create the user's home directory
IIRC, enewuser allowed extra arguments to useradd previously —
however, this feature was removed, probably because enewuser-like
functions are supposed to be multi-platform. I think that -M didn't
work even back then, since home directory is created explicitly by
enewuser.