Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
On Mon, Jan 20, 2020 at 06:07:06PM -0500, Michael Orlitzky wrote: > As I've said, a human uses the "amavis" account. I think this statement here needs a bit of expansion, and thus it more clarity happens. Your aforementioned human generally doesn't use the 'amavis' account in the same way that they might use a normal account. They don't expect to login to it with GNOME/SSH and run typical user applications (Libreoffice, Nethack etc.). It's a system account that CAN get configured by a human manually becoming that user. Either by login or means of changing effective UID (su, sudo, doas, ksu, pmrun, runas, ...). For a more secure environment, I would expect amavis to never have a password and thus not be subject to normal login flows. Gentoo Infra manages amavis & spamd without logging in as a human: configuration management is used to change settings & files. From this, I posit that something OUTSIDE of /home is the most-correct location. /srv or /var. Upstream uses /var/amavis Debian uses /var/lib/amavis I'm sympathetic to past users who have /home/amavisd and need to migrate it, but such is the nature of sysadmin life. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
On 1/21/20 6:44 AM, Jaco Kroon wrote: > > There is technically no real issue, but it's the right thing to do. > > Right, motivations for your proposal for allowing this: > > * You want it. > > Motivations against: > This is dishonest. "I want it" because it improves some things for our users, which you've purposely omitted. I was never going to commit the patch. If anyone wants to discuss the technical merits of using /home, I find it interesting, but please let this thread die and just email me personally or ping me on IRC.
Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
Hi Michael,
My background: 21 years of Linux, 18 of which was primarily on Gentoo.
17 years of no other OS other than Linux. Ex-sysadmin for a largish
setup with 4000+ active users, and ~500-600 available workstations and a
number of storage and other servers. Not to brag, just to give you an
idea of my background and experience.
I am against this patch.
On 2020/01/20 16:20, Michael Orlitzky wrote:
> On 1/20/20 2:02 AM, Ulrich Mueller wrote:
>>> On Mon, 20 Jan 2020, Michael Orlitzky wrote:
>>> install-qa-check.d: allow acct-user home directories under /home.
>> Nope. As you've been told, /home is site specific and can be setup in
>> multiple ways that are incompatible with the package manager installing
>> things there (the only exception being baselayout creating the directory
>> itself).
> I haven't been given a single technical reason why using /home would
> cause a problem. What specific incompatibilities are you talking about?
>From my perspective the following should be adequate:
There is technically no real issue, but it's the right thing to do.
Right, motivations for your proposal for allowing this:
* You want it.
Motivations against:
* /home belongs to the sys-admin. In above environment if you were to
mess with my /home, I'd be very, very angry.
* installing stuff into /home using system-local UIDs has potential
security impacts if /home is distributed (user id conflicts).
* People mentioned encrypted home folders using LUKS ... these typically
mount on /home/${username} so I personally think this is less of an issue.
* FHS standards (back to it's the right thing to do).
* I've worked on numerous distributions (Debian, Ubuntu, RHEL, SuSE,
Fedora, Mint, IMPI, knoppix ... probably others) and not once have I
encountered system packages messing with /home. Not having encountered
it doesn't say there isn't any, just that I've not encountered them.
>
>
>> Quoting FHS-3.0 again:
>>
>> | On large systems (especially when the /home directories are shared
>> | amongst many hosts using NFS) it is useful to subdivide user home
>> | directories. Subdivision may be accomplished by using subdirectories
>> | such as /home/staff, /home/guests, /home/students, etc.
>>
>> So, how are you going to detect if such a scheme is used on the system,
>> and in which subdirectory the amavis user should be placed?
> The same way we detect that scheme before setting a home directory to
> /var/lib/whatever, which you may notice, is not under /home/guests or
> anything like that. Does this cause a real technical problem, or is it
> just more FUD?
It's not FUD, there is no fear here, no uncertainty, no doubt. We don't
*want* you to touch /home. We want you to use /var/lib.
>
>> I also wonder why you would send this patch, when there wasn't a single
>> voice supporting your proposition in the other thread and several
>> opposing ones.
> I don't want to just complain without offering a solution.
>
> No one has pointed out any problems with it.
>
> This stuff is already in /home, and I'd like to get off user.eclass
> without introducing a new QA warning for a keepdir file.
Use /var/lib/amavis/work and /var/lib/amavis/home. Simple.
Kind Regards,
Jaco
Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
On 1/20/20 5:08 PM, Alec Warner wrote: > > So I can describe in detail one example, but its not running Gentoo; so > I'm not sure if you care in practice. Yes, I'm happy to see a real example. > At work we had sec=krb5 NFS v3 mounted home directories. They were > mounted in /home (via the automounter.) So if these machines ran Gentoo > and you went to do something like "create /home/amavisd" it would fail > because the root user doesn't have the ability to make home directories > in /home (uid=0 is mapped to nobody, who doesn't have +w on /home.) All > home directories were created by a business application and there were > specific hosts where root was not squashed (and we used sec=sys instead > of krb5) and so root on the admin host would have +w on /home and not be > squashed to nobody.) > > In practice in that enterprise environment, if we needed something like > /home/web/ (which I think did exist at one point) we would create a role > account in LDAP (www-data is a common user for example), assign it a > uid, create the homedirectory (/home/web) and it would be owned by > www-data:www-data. Then we would configure the web front ends to use > www-data instead of the normal user (apache or nginx or whatever.) That's all relatively normal. As I've said, a human uses the "amavis" account. Yes, the install of acct-user/amavis would crash because it can't create the home directory, but I contend that crashing is the best thing to do. When the acct-user ebuild crashes, you get to ask yourself if you want his home directory to be shared among the people with authority to release spam from the quarantine. I'm betting you would, and that you would therefore add the account to LDAP and start over. Same deal as apache/web, and you don't have to involve an overlay to do the right thing. In this case, the fact that we used /home was a boon, because it helped you accomplish what you were trying to accomplish by sharing /home in the first place. If you don't want to share the home directory... well, no harm done. You'll have to override the ebuild to tell it what location to use as an alternative. But I think this case is somewhat less likely, and the base rate was already single digits. If only good exceptions are made (with home directories that people would actually want to share under /home), this approach does a little good and no bad. > (2) I don't think most people running Gentoo are running these > environments, which is why you don't see many practical objections on > the list. I think it's reasonable to avoid service account homedirs in > /home not because of fancy examples like above (that maybe 10 companies > in the world run) and instead just focus on this idea that "system stuff > doesn't go in /home." Its somewhat arbitrary as mgorny points out > earlier in the thread. I was never discounting these sorts of environments. On the contrary, the point I'm trying to make above appeared somewhere in the discussion with rich0, but it's hard to articulate without details. If it's arbitrary and we admit that, I'm fine with it. I'm moving on with my life. QA can choose what kind of sauce users get on their turd sandwich =P
Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
On Mon, Jan 20, 2020 at 6:20 AM Michael Orlitzky wrote: > On 1/20/20 2:02 AM, Ulrich Mueller wrote: > >> On Mon, 20 Jan 2020, Michael Orlitzky wrote: > > > >> install-qa-check.d: allow acct-user home directories under /home. > > > > Nope. As you've been told, /home is site specific and can be setup in > > multiple ways that are incompatible with the package manager installing > > things there (the only exception being baselayout creating the directory > > itself). > > I haven't been given a single technical reason why using /home would > cause a problem. What specific incompatibilities are you talking about? > So I can describe in detail one example, but its not running Gentoo; so I'm not sure if you care in practice. At work we had sec=krb5 NFS v3 mounted home directories. They were mounted in /home (via the automounter.) So if these machines ran Gentoo and you went to do something like "create /home/amavisd" it would fail because the root user doesn't have the ability to make home directories in /home (uid=0 is mapped to nobody, who doesn't have +w on /home.) All home directories were created by a business application and there were specific hosts where root was not squashed (and we used sec=sys instead of krb5) and so root on the admin host would have +w on /home and not be squashed to nobody.) In practice in that enterprise environment, if we needed something like /home/web/ (which I think did exist at one point) we would create a role account in LDAP (www-data is a common user for example), assign it a uid, create the homedirectory (/home/web) and it would be owned by www-data:www-data. Then we would configure the web front ends to use www-data instead of the normal user (apache or nginx or whatever.) In practice: (1) These environments are what I'd consider legacy; if I was crafting an enterprise environment today I would not design one quite like this[0]. (2) I don't think most people running Gentoo are running these environments, which is why you don't see many practical objections on the list. I think it's reasonable to avoid service account homedirs in /home not because of fancy examples like above (that maybe 10 companies in the world run) and instead just focus on this idea that "system stuff doesn't go in /home." Its somewhat arbitrary as mgorny points out earlier in the thread. -A [0] Linux has really poor machine trust by default and while you can build a ragtag set of primitives to trust machines and identities; I think the effort is better spent shelling out money for some kind of real identity management provider that isn't just 'hey here is a uid + ip' which is how we did things in the 90s man. It was an innocent time ;) > > > Quoting FHS-3.0 again: > > > > | On large systems (especially when the /home directories are shared > > | amongst many hosts using NFS) it is useful to subdivide user home > > | directories. Subdivision may be accomplished by using subdirectories > > | such as /home/staff, /home/guests, /home/students, etc. > > > > So, how are you going to detect if such a scheme is used on the system, > > and in which subdirectory the amavis user should be placed? > > The same way we detect that scheme before setting a home directory to > /var/lib/whatever, which you may notice, is not under /home/guests or > anything like that. Does this cause a real technical problem, or is it > just more FUD? > > > > I also wonder why you would send this patch, when there wasn't a single > > voice supporting your proposition in the other thread and several > > opposing ones. > > I don't want to just complain without offering a solution. > > No one has pointed out any problems with it. > > This stuff is already in /home, and I'd like to get off user.eclass > without introducing a new QA warning for a keepdir file. > >
Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
On 1/20/20 1:39 PM, Michał Górny wrote: > > I'm going to be blunt. We arbitrarily made a decision that /home > belongs to sysadmin. Please respect that. If you really believe your > package is *this* special to justify changing this arbitrary decision, > the burden of proof lies on you. > Ok. How to move forward? The old user.eclass allowed using /home, and we have packages using /home. One of them is spamd, and I've beaten to death the reasons why I think that's the best choice. I would rather not move it somewhere *less* appropriate on principle. I would also like to not break running mail systems the second the acct-user package is emerged. What are the options? * Upgrade to GLEP81 anyway and ignore the warning (my interim plan). * Hack the acct-user ebuild so that it doesn't trigger the warning, by bypassing $D. * Leave it on user.eclass. * ???
Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
On Mon, 2020-01-20 at 10:20 -0500, Michael Orlitzky wrote: > On 1/20/20 9:50 AM, David Seifert wrote: > > Rich has given reasons, ulm has, and mgorny suggested a solution. > > > > Everyone's real intent on saying that there are problems without > actually typing what those problems are into the email box. > > We're talking about a single keepdir file here. > > Please describe in detail the havoc that this could cause and under what > precise circumstances. > I'm going to be blunt. We arbitrarily made a decision that /home belongs to sysadmin. Please respect that. If you really believe your package is *this* special to justify changing this arbitrary decision, the burden of proof lies on you. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
On 1/20/20 1:01 PM, Ulrich Mueller wrote: > > It's just awful to have a one user at second level (like /home/amavis) > when all others are at third level (like /home/staff/joe). > Finally an honest argument =) I agree. But all we're doing is choosing the default here. GLEP81 lets the user override the home directory in those rare cases to put it under /home/guests. For everyone else, you get /home/user1 /home/user2 /home/user3 /home/user4 instead of /home/user1 /home/user2 /var/lib/user3/home /home/user4 I think it's weird that my bash_history winds up under /var/lib. > Besides, nothing guarantees that your username under /home won't collide > with an existing subdirectory name. You can make the same argument about /var/lib. And keep in mind that we already have "collisions" for $HOME every time someone switches from user.eclass to a GLEP81 user. The risk for /home is no greater than anywhere else, and we've deemed that risk acceptable, whatever it is.
Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
> On Mon, 20 Jan 2020, Michael Orlitzky wrote: > On 1/20/20 2:02 AM, Ulrich Mueller wrote: >> Quoting FHS-3.0 again: >> >> | On large systems (especially when the /home directories are shared >> | amongst many hosts using NFS) it is useful to subdivide user home >> | directories. Subdivision may be accomplished by using subdirectories >> | such as /home/staff, /home/guests, /home/students, etc. >> >> So, how are you going to detect if such a scheme is used on the system, >> and in which subdirectory the amavis user should be placed? > The same way we detect that scheme before setting a home directory to > /var/lib/whatever, which you may notice, is not under /home/guests or > anything like that. Does this cause a real technical problem, or is it > just more FUD? It's just awful to have a one user at second level (like /home/amavis) when all others are at third level (like /home/staff/joe). Besides, nothing guarantees that your username under /home won't collide with an existing subdirectory name. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
On 1/20/20 9:50 AM, David Seifert wrote: > > Rich has given reasons, ulm has, and mgorny suggested a solution. > Everyone's real intent on saying that there are problems without actually typing what those problems are into the email box. We're talking about a single keepdir file here. Please describe in detail the havoc that this could cause and under what precise circumstances.
Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
On Mon, 2020-01-20 at 09:20 -0500, Michael Orlitzky wrote: > On 1/20/20 2:02 AM, Ulrich Mueller wrote: > > > > > > > On Mon, 20 Jan 2020, Michael Orlitzky wrote: > > > install-qa-check.d: allow acct-user home directories under > > > /home. > > > > Nope. As you've been told, /home is site specific and can be setup > > in > > multiple ways that are incompatible with the package manager > > installing > > things there (the only exception being baselayout creating the > > directory > > itself). > > I haven't been given a single technical reason why using /home would > cause a problem. What specific incompatibilities are you talking > about? > > > > Quoting FHS-3.0 again: > > > > > On large systems (especially when the /home directories are > > > shared > > > amongst many hosts using NFS) it is useful to subdivide user home > > > directories. Subdivision may be accomplished by using > > > subdirectories > > > such as /home/staff, /home/guests, /home/students, etc. > > > > So, how are you going to detect if such a scheme is used on the > > system, > > and in which subdirectory the amavis user should be placed? > > The same way we detect that scheme before setting a home directory to > /var/lib/whatever, which you may notice, is not under /home/guests or > anything like that. Does this cause a real technical problem, or is > it > just more FUD? Rich has given reasons, ulm has, and mgorny suggested a solution. > > > I also wonder why you would send this patch, when there wasn't a > > single > > voice supporting your proposition in the other thread and several > > opposing ones. > > I don't want to just complain without offering a solution. > > No one has pointed out any problems with it. Multiple people have pointed out issues with it in the last thread. In fact, noone has said "great, go ahead". > > This stuff is already in /home, and I'd like to get off user.eclass > without introducing a new QA warning for a keepdir file. >
Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
On 1/20/20 2:02 AM, Ulrich Mueller wrote: >> On Mon, 20 Jan 2020, Michael Orlitzky wrote: > >> install-qa-check.d: allow acct-user home directories under /home. > > Nope. As you've been told, /home is site specific and can be setup in > multiple ways that are incompatible with the package manager installing > things there (the only exception being baselayout creating the directory > itself). I haven't been given a single technical reason why using /home would cause a problem. What specific incompatibilities are you talking about? > Quoting FHS-3.0 again: > > | On large systems (especially when the /home directories are shared > | amongst many hosts using NFS) it is useful to subdivide user home > | directories. Subdivision may be accomplished by using subdirectories > | such as /home/staff, /home/guests, /home/students, etc. > > So, how are you going to detect if such a scheme is used on the system, > and in which subdirectory the amavis user should be placed? The same way we detect that scheme before setting a home directory to /var/lib/whatever, which you may notice, is not under /home/guests or anything like that. Does this cause a real technical problem, or is it just more FUD? > I also wonder why you would send this patch, when there wasn't a single > voice supporting your proposition in the other thread and several > opposing ones. I don't want to just complain without offering a solution. No one has pointed out any problems with it. This stuff is already in /home, and I'd like to get off user.eclass without introducing a new QA warning for a keepdir file.
Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
> On Mon, 20 Jan 2020, Michael Orlitzky wrote: > install-qa-check.d: allow acct-user home directories under /home. Nope. As you've been told, /home is site specific and can be setup in multiple ways that are incompatible with the package manager installing things there (the only exception being baselayout creating the directory itself). Quoting FHS-3.0 again: | On large systems (especially when the /home directories are shared | amongst many hosts using NFS) it is useful to subdivide user home | directories. Subdivision may be accomplished by using subdirectories | such as /home/staff, /home/guests, /home/students, etc. So, how are you going to detect if such a scheme is used on the system, and in which subdirectory the amavis user should be placed? I also wonder why you would send this patch, when there wasn't a single voice supporting your proposition in the other thread and several opposing ones. Ulrich signature.asc Description: PGP signature
