public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] GLEP81 and /home
Date: Sun, 19 Jan 2020 20:20:28 -0500	[thread overview]
Message-ID: <CAGfcS_kJJ14QWd0PFHeEOR4viBTrzNKUZPDR0OsaxSwhvtk_FQ@mail.gmail.com> (raw)
In-Reply-To: <5e98c62e-3501-9322-7129-a9d6105a6126@gentoo.org>

On Sun, Jan 19, 2020 at 4:00 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On 1/19/20 2:47 PM, Rich Freeman wrote:
> >
> > Obviously the UIDs associated with the shared /home need to be
> > identical.  Simplest solution is to sync anything > 1000 in
> > /etc/passwd, and then not allow UIDs below 1000 in /home.  A cron job
> > could easily handle both, and of course regular users can't go
> > creating stuff with the wrong UID anyway.
>
> That's not enough. You also need to sync any user/group that appears as
> the owner or group of a file in /home, and every user/group that appears
> in an ACL in /home, and so on. And since you have no idea what files or
> access control lists will show up in /home, you'd better sync them all.

That doesn't seem reasonable, considering that this could require
syncing across various Distros, or even various Unix-like OSes.
It would be far simpler for the sysadmin to simply ensure that no
unsynced user owns a file or appears in an ACL.  That would be pretty
trivial to achieve.  Whatever is hosting /home could be designed to
block such changes, or you could just scan for these ownership issues
periodically and treat those responsible for them appropriately.

In any case, maintaining permissions on stuff in /home is a sysadmin
responsibility, not a distro responsibility.

On Sun, Jan 19, 2020 at 5:09 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> Just kidding, the eclass is rigged to die in src_install if you delete
> the home directory, and if you wait until pkg_preinst, the warning gets
> shown anyway (for a file that's not there, noice).
>
> Guess we'll be triggering a warning after all.

On the topic of treating those responsible appropriately, somehow I
could see this scenario turning into a quiz question.

I mean, would it kill you to just talk to QA first?

-- 
Rich


  parent reply	other threads:[~2020-01-20  1:20 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-18 17:51 [gentoo-dev] GLEP81 and /home Michael Orlitzky
2020-01-18 18:10 ` Ulrich Mueller
2020-01-18 23:38   ` Michael Orlitzky
2020-01-19  0:21     ` Rich Freeman
2020-01-19  2:50       ` Michael Orlitzky
2020-01-19 11:29         ` Rich Freeman
2020-01-19 15:49           ` Michael Orlitzky
2020-01-19 17:42             ` Rich Freeman
2020-01-19 18:37               ` Michael Orlitzky
2020-01-19 19:02                 ` Rich Freeman
2020-01-19 19:27                   ` Michael Orlitzky
2020-01-19 19:47                     ` Rich Freeman
2020-01-19 21:00                       ` Michael Orlitzky
2020-01-19 22:09                         ` Michael Orlitzky
2020-01-20  1:20                         ` Rich Freeman [this message]
2020-01-20  1:51                           ` Michael Orlitzky
2020-01-20  2:52                             ` Rich Freeman
2020-01-20  3:16                               ` Michael Orlitzky
2020-01-20  3:40                                 ` Rich Freeman
2020-01-20  3:57                                   ` Michael Orlitzky
2020-01-19 19:37             ` Robin H. Johnson
2020-01-19 19:19         ` Alec Warner
2020-01-19 19:28           ` Michael Orlitzky
2020-01-19 19:32             ` Alec Warner
2020-01-19 20:44               ` Michael Orlitzky
2020-01-18 19:03 ` Alec Warner
2020-01-18 20:16   ` Michael Orlitzky
2020-01-18 19:08 ` Michał Górny
2020-01-18 19:44   ` Michael Orlitzky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGfcS_kJJ14QWd0PFHeEOR4viBTrzNKUZPDR0OsaxSwhvtk_FQ@mail.gmail.com \
    --to=rich0@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox