Re: [gentoo-dev] usr merge

[William Hubbs]

On Sat, Apr 09, 2016 at 12:06:47AM -0400, Anthony G. Basile wrote:
> On 4/8/16 11:03 PM, Rich Freeman wrote:
> > On Fri, Apr 8, 2016 at 9:51 PM, Anthony G. Basile <blueness@g.o> wrote:
> >>
> >> Alternatively, this may introduce problems.  So it seems like we're
> >> fixing something that isn't broken.
> >>
> >
> > What problems are you anticipating, especially in light of the fact
> > that many distros actually do it this way already?
>
> RBAC policy files for one.  You'll probably break every single hardened
> gentoo server out there.
 
 Tell me more about this; I don't know a lot about what would break.
 Also, are you sure it would break, or are you just thinking that it
 would?

> scripts and programs that assume different executables with the same
> name at different points along the path, eg I know a company where
> they've set up an ssh wrapper at /usr/local/bin/ssh which wrap /usr/bin/ssh.
 
 This won't break, because /usr/bin/ssh would still exist as it does and
 /usr/local is not touched.

File colissions between the directories that are being merged would
definitely be an issue that needs to be worked out before this could
happen, and I understand that. I know of at least one, and we would need
to find out if there are others.

Forgetting about /usr/local since we don't control that, this type of
file name collision across the bin directories is not good whether or
not you merge /usr. It would cause issues in path name resolution.

> security measures where you don't dereference sym links along $PATH
> because sym links can be used in various types of exploits.
 
Every amd64 gentoo system already has one of these, the "lib" symlink,
both in / and /usr, so if you aren't dereferencing symlinks, aren't you
already broken?

> >
> > I don't really have a problem with making it optional or the default.
>
> if we don't make it optional we're going to cause some serious headaches
> for people who are invested in the current status quo.
>
> >
> > It can also be left up to the maintainers, and of course somebody
> > could even fork baselayout/etc if they wish and virtualize it in
> > @system.  Most things in Gentoo don't actually require a consensus to
> > move forward, especially if they aren't defaults.
>
> if we deprecate the linker scripts in /usr/lib by stubbing out
>gen_usr_ldscript, then its not as simple as "maintainer's choice".

gen_usr_ldscript is only needed if you are using separate /usr without
an initramfs. This is unsupported and orthogonal to the usr merge.
 
> >
> > In any case, what is the point of this thread?  If somebody wants to
> > implement a merged /usr what exactly is stopping them from doing so?
>
> i'm against something that doesn't maintain backwards compat.

If there are ways that merging / into /usr does not maintain backward
compatibility, I want to know what they are.

This is not directed at anyone specifically, it is just a general
comment.

I've seen a lot of speculation on this thread about what might break,
and a lot of comments about a perceived removal  of choice.

Can someone help get a summary together? let's get a single message
summarizing everything.

Thanks,

William