From: russell@coker.com.au (Russell Coker) Date: Thu, 9 Mar 2017 02:00:53 +1100 Subject: [refpolicy] [PATCH 1/1] Support systems with a single /usr/bin directory In-Reply-To: <3edaac52-76c2-f443-d982-07a6c4cf13d5@ieee.org> References: <20170305143659.12026-1-nicolas.iooss@m4x.org> <3edaac52-76c2-f443-d982-07a6c4cf13d5@ieee.org> Message-ID: <201703090200.53182.russell@coker.com.au> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Wed, 8 Mar 2017 12:13:50 PM Chris PeBenito via refpolicy wrote: > >> What do you think will happen with other distributions in this > >> regard? If they will do it too then option 5 would be the obvious > >> correct solution. > > > > I have not heard anything about projects to merge /usr/sbin with > > /usr/bin in any other distribution than Arch Linux-based ones and Arch > > Linux has done it nearly 4 years ago > > (https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update- > > intervention/). As I expect such a change to be handled like the /usr > > merge (with an announcement so that packages get updated), I believe it > > will not happen in the near future. > > I've been wondering about #5 myself. A lot of the differences between > bin and sbin seem to be very arbitrary. I don't think there's anything > to gain by treating them separately. I've done a quick grep and sort for unique names between /usr/bin and /usr/sbin and found that there are 1129 unique entries and 39 duplicates. I only checked for obvious duplicates, there could be less obvious ones like "ab[cd]" vs separate entries for "abc" and "abd". These duplicates increase the possibility of a policy change relabelling an executable not covering all instances. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/