Re: [gentoo-dev] [PATCH 1/1] ebuild-writing/users-and-groups: GLEP 81 user data guidelines.

2019-09-02 Thread Michael Orlitzky
On 9/2/19 12:32 PM, Mike Gilbert wrote:
> 
> I can't really agree with the advice given in this section.
> 
> If I'm maintaining a package and an associated acct-user package, I'm
> going to keep the two in sync. I don't see why I should have to create
> a directory via pkg_postinst when I could allow the acct-user package
> to do it for me.
> 
> That the data is "non-local" is irrelevant if I'm maintaining both ebuilds.
> 

We already have similar policies for other sorts of dependencies. If
your package links to libfoo, then libfoo goes in RDEPEND even if it
would be pulled in by some other dependency that you maintain.
Developers retire and packages change hands all the time -- having an
implicit dependency is asking for trouble, especially considering that
the explicit approach isn't much more onerous: it's one extra line. To
the next guy, the dependency won't be implicit, it will be nonexistent.
Whether you find this reasoning persuasive or not, there is at least
some precedent for it.

In the acct-user case, both methods will result in the directory being
keepdir'd. But ultimately, the point I'm trying to make in the patch is
that one method will always work while the other might not if something
outside of your control changes. Neither is more difficult, so why not
choose the way that always works, and set up the directory in the ebuild
that uses it?

User packages can be shared and home directories can change by the
design of GLEP81. You can't guarantee that no one else is going to
depend on your acct-user package, or that its home directory will never
have to change, or that you will maintain both of them forever. In any
of those situations, having the directory creation be a side effect of
enewuser is a bad idea. Why should my package create your package's
localstatedir just because I want to share a username? And why should I
have to violate the principle of least privilege, giving my user a home
directory it doesn't need? Yeah, we could address those problems when
they arise; but if they can be avoided entirely by an extra call or two
to fowners/fperms, I think it's worth doing so. Or at least worth
*suggesting* that we do so.

If any of this is more persuasive than the original, I can update the
patch. If not, I can, uh, try harder.



Re: [gentoo-dev] [PATCH 1/1] ebuild-writing/users-and-groups: GLEP 81 user data guidelines.

2019-09-02 Thread Mike Gilbert
On Sun, Sep 1, 2019 at 1:48 PM Michael Orlitzky  wrote:
> +
> +  Choosing a home directory
> +  
> +
> +  In most cases, the default home directory (that is, no home
> +  directory) should be used. GLEP81 changed two aspects of user
> +  management with respect to home directories:
> +
> +
> +
> +  
> +   Creating a user can now modify the permissions on an existing
> +   directory. Should the need arise, this is necessary for a new
> +   version of an acct-user package to be able to fix the
> +   ownership and permissions of its home directory.
> +  
> +  
> +   All user data aside from the username became non-local to
> +   ebuilds that depend on that user. This is merely a side-effect
> +   of moving the user creation out of the client package, and
> +   into a separate acct-user package.
> +  
> +
> +
> +
> +  The first item means that you should be conservative when
> +  choosing a home directory. If at all possible, avoid choosing a
> +  home directory that is used by another package. In particular,
> +  no two acct-user packages should use the same home
> +  directory. At best, the ownership and permissions on a shared
> +  home directory would need to be kept synchronized between all
> +  packages that share it. At worst, one package goes out-of-sync
> +  and introduces a security hole for the others who no longer have
> +  the expected permissions.
> +
> +
> +
> +  The second item means that if your package requires a user, you
> +  can no longer be sure of that user's home directory or its
> +  ownership and permissions. If your package requires a directory
> +  to be owned and writable by some user, then your package's
> +  ebuild should create that directory and ensure that it is
> +  writable by the user. In other words, you should not rely on the
> +  directory being created "transitively" by a dependency, even if
> +  that dependency is an acct-user package.
> +

I can't really agree with the advice given in this section.

If I'm maintaining a package and an associated acct-user package, I'm
going to keep the two in sync. I don't see why I should have to create
a directory via pkg_postinst when I could allow the acct-user package
to do it for me.

That the data is "non-local" is irrelevant if I'm maintaining both ebuilds.