Re: [gentoo-dev] RFC: GLEP81 home directory guidelines

2019-08-16 Thread Haelwenn (lanodan) Monnier
[2019-08-16 18:40:32-0400] Michael Orlitzky:
> GLEP81 changed two aspects of user management:
> 
>   1 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
> 
>   2 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. 

Any reason why sharing home directories isn't simply forbidden?
This is sure to blow on us at some point if there is shared home directories.

>   1 Avoid using an ACCT_USER_HOME that belongs to another package.
> 
>   2 No two acct-user packages should define the same ACCT_USER_HOME.

I feel like this is redundant, even if you would want to also cover
pre-acct-user packages.

>   3 If your package's configuration needs  to be able to
> write to e.g. /var/lib/, then your package's ebuild should
> create that directory and set its ownership and permissions. Barring
> any other considerations, the corresponding acct-user package should
> leave ACCT_USER_HOME at its default (empty) value; setting
> ACCT_USER_HOME=/var/lib/ would violate item (1).
> 
>   4 Each user's home directory should be writable by that user. If it
> is not, that indicates that a shared and potentially sensitive
> location was chosen; and the fact that the home directory is not
> writable suggests that the default (empty) ACCT_USER_HOME would
> suffice instead.

Shouldn't this be owned instead of writable? I'm pretty sure we can 
have cases where no having write permissions is prefered for security.

>   5 As a corollary of the previous item, it is highly suspicious for
> an acct-user package to set ACCT_USER_HOME_OWNER="root:root".

Is there cases where this would be used? It makes no sense to me for a 
home to belong to root.



[gentoo-dev] RFC: GLEP81 home directory guidelines

2019-08-16 Thread Michael Orlitzky
Pending https://github.com/gentoo/devmanual.gentoo.org/pull/99, I'd like
to get something like this written down.

Please give it a quick read and see if it makes sense, or if I've
overlooked anything. Most of these would just be suggestions, to be
implemented as post-install QA checks or repoman warnings.


== Choosing a home directory ==

GLEP81 changed two aspects of user management:

  1 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

  2 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, if one
package goes out-of-sync, it introduces a security hole for the other
packages who no longer have the permissions they expect.

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," as
one of your acct-user dependencies' home directories---because that
home directory can change.

These considerations motivate the following guidelines for GLEP81 home
directories, all of which can be summarized as,

 ** If the default (empty) value of ACCT_USER_HOME will work, use it. **

Specifically,

  1 Avoid using an ACCT_USER_HOME that belongs to another package.

  2 No two acct-user packages should define the same ACCT_USER_HOME.

  3 If your package's configuration needs  to be able to
write to e.g. /var/lib/, then your package's ebuild should
create that directory and set its ownership and permissions. Barring
any other considerations, the corresponding acct-user package should
leave ACCT_USER_HOME at its default (empty) value; setting
ACCT_USER_HOME=/var/lib/ would violate item (1).

  4 Each user's home directory should be writable by that user. If it
is not, that indicates that a shared and potentially sensitive
location was chosen; and the fact that the home directory is not
writable suggests that the default (empty) ACCT_USER_HOME would
suffice instead.

  5 As a corollary of the previous item, it is highly suspicious for
an acct-user package to set ACCT_USER_HOME_OWNER="root:root".

  6 The world-writable bit should never be set in ACCT_USER_HOME_PERMS.
This would otherwise satisfy item (4), but should never be done for
security reasons.



[gentoo-dev] meson.eclass: meson_src_{compile,install}: Pass "$@" to

2019-08-16 Thread Mike Gilbert
Please review this patch.

https://670788.bugs.gentoo.org/attachment.cgi?id=587064



[gentoo-portage-dev] [PATCH] sys-apps/portage: depend on iproute2 on Linux

2019-08-16 Thread Mike Gilbert
This should ensure that /bin/ip is available during early stage builds.

Package-Manager: Portage-2.3.71_p6, Repoman-2.3.17_p5
Signed-off-by: Mike Gilbert 
---
 sys-apps/portage/portage-2.3.71.ebuild | 5 -
 sys-apps/portage/portage-.ebuild   | 5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/sys-apps/portage/portage-2.3.71.ebuild 
b/sys-apps/portage/portage-2.3.71.ebuild
index 969ce20d8767..4a0a61a97b5f 100644
--- a/sys-apps/portage/portage-2.3.71.ebuild
+++ b/sys-apps/portage/portage-2.3.71.ebuild
@@ -54,7 +54,10 @@ RDEPEND="
elibc_glibc? ( >=sys-apps/sandbox-2.2 )
elibc_musl? ( >=sys-apps/sandbox-2.2 )
elibc_uclibc? ( >=sys-apps/sandbox-2.2 )
-   kernel_linux? ( sys-apps/util-linux )
+   kernel_linux? (
+   sys-apps/iproute2
+   sys-apps/util-linux
+   )
>=app-misc/pax-utils-0.1.17
selinux? ( >=sys-libs/libselinux-2.0.94[python,${PYTHON_USEDEP}] )
xattr? ( kernel_linux? (
diff --git a/sys-apps/portage/portage-.ebuild 
b/sys-apps/portage/portage-.ebuild
index e7c1e8c638fe..8f7a65da1eb8 100644
--- a/sys-apps/portage/portage-.ebuild
+++ b/sys-apps/portage/portage-.ebuild
@@ -54,7 +54,10 @@ RDEPEND="
elibc_glibc? ( >=sys-apps/sandbox-2.2 )
elibc_musl? ( >=sys-apps/sandbox-2.2 )
elibc_uclibc? ( >=sys-apps/sandbox-2.2 )
-   kernel_linux? ( sys-apps/util-linux )
+   kernel_linux? (
+   sys-apps/iproute2
+   sys-apps/util-linux
+   )
>=app-misc/pax-utils-0.1.17
selinux? ( >=sys-libs/libselinux-2.0.94[python,${PYTHON_USEDEP}] )
xattr? ( kernel_linux? (
-- 
2.23.0.rc2




Re: [gentoo-dev] [RFC] package.deprecated to mark packages deprecated and report dependencies

2019-08-16 Thread Thomas Deutschmann
Hi,

I like the idea. This will allow the following change in workflow:

When you now want to last-rite app-misc/foo for example, you would
schedule a CI run. I.e. create a pull request against Gentoo repository
at GitHub containing your package.mask entry. When the results will be
available, you will start filling bugs against packages depending on the
package you want to get rid off. Once all depending packages are gone,
you will commit the mask. However, this process can take some time and
in theory someone could add a new dependency on your package in the
meanwhile...

Thanks to the new package.deprecated file we would have a check in real
time against current repository. And once all CI warnings are gone you
can commit the mask.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [RFC] package.deprecated to mark packages deprecated and report dependencies

2019-08-16 Thread Michał Górny
Hi,

leio asked me yesterday for the possibility of marking packages
as deprecated, so that CI would issue warnings when other packages
depend on them.  I think that's quite a good idea, so I'd like to
propose a simple implementation for it.

The idea is to provide profiles/package.deprecated using the same format
as package.mask.  However, unlike the latter it wouldn't cause any user-
visible results but only affect pkgcheck (and possibly repoman, if
someone writes the check).

Basically you'd put something like:

  # name  (date)
  # We don't like this package anymore, so we want to remove it ASAP.
  dev-foo/bar

  # name  (date)
  # Old slot is not nice at all.
  dev-bar/frobnicate:0.1

  # name  (date)
  # Nononono, don't use that.
  

signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH] check-reqs.eclass: check-reqs_memory(): Check for available swap.

2019-08-16 Thread Ulrich Mueller
From: Arfrever Frehtes Taifersar Arahesis 
Date: Mon, 13 May 2019 16:30:15 +0200

Print warning if usage of swap appears to be needed.

Closes: https://bugs.gentoo.org/569966
Signed-off-by: Arfrever Frehtes Taifersar Arahesis 
Signed-off-by: Ulrich Müller 
---
 eclass/check-reqs.eclass | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
index 689944c8770..feb0b2fdbfd 100644
--- a/eclass/check-reqs.eclass
+++ b/eclass/check-reqs.eclass
@@ -1,3 +1,3 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 2004-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
@@ -241,33 +241,43 @@
 check-reqs_memory() {
debug-print-function ${FUNCNAME} "$@"
 
[[ -z ${1} ]] && die "Usage: ${FUNCNAME} [size]"
 
local size=${1}
local actual_memory
+   local actual_swap
 
check-reqs_start_phase \
${size} \
"RAM"
 
if [[ -r /proc/meminfo ]] ; then
actual_memory=$(awk '/MemTotal/ { print $2 }' /proc/meminfo)
+   actual_swap=$(awk '/SwapTotal/ { print $2 }' /proc/meminfo)
else
-   actual_memory=$(sysctl hw.physmem 2>/dev/null )
+   actual_memory=$(sysctl hw.physmem 2>/dev/null)
[[ "$?" == "0" ]] &&
-   actual_memory=$(echo $actual_memory | sed -e 
's/^[^:=]*[:=]//' )
+   actual_memory=$(echo "${actual_memory}" | sed -e 
's/^[^:=]*[:=][[:space:]]*//')
+   actual_swap=$(sysctl vm.swap_total 2>/dev/null)
+   [[ "$?" == "0" ]] &&
+   actual_swap=$(echo "${actual_swap}" | sed -e 
's/^[^:=]*[:=][[:space:]]*//')
fi
if [[ -n ${actual_memory} ]] ; then
-   if [[ ${actual_memory} -lt $(check-reqs_get_kibibytes ${size}) 
]] ; then
+   if [[ ${actual_memory} -ge $(check-reqs_get_kibibytes ${size}) 
]] ; then
+   eend 0
+   elif [[ -n ${actual_swap} && $((${actual_memory} + 
${actual_swap})) -ge $(check-reqs_get_kibibytes ${size}) ]] ; then
+   ewarn "Amount of main memory is insufficient, but 
amount"
+   ewarn "of main memory combined with swap is sufficient."
+   ewarn "Build process may make computer very slow!"
+   eend 0
+   else
eend 1
check-reqs_unsatisfied \
${size} \
"RAM"
-   else
-   eend 0
fi
else
eend 1
ewarn "Couldn't determine amount of memory, skipping..."
fi
 }
-- 
2.22.1


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] acct-user.eclass: ignore missing directory in preinst

2019-08-16 Thread Jaco Kroon
Hi,

On 2019/08/15 16:47, Mike Gilbert wrote:

> On Thu, Aug 15, 2019 at 8:33 AM Michael Orlitzky  wrote:
>> On 8/15/19 3:19 AM, Ulrich Mueller wrote:
>>> I don't think that's a sane situation, so maybe the eclass should just
>>> die here? (Basically, there are two possibilities: Either, things will
>>> break if the dir is missing, then dying might be the best option.
>>> Or, everything works without the dir, then the ebuild should set it to
>>> /dev/null, in the first place.)
>>>
>> That's my feeling as well. In 100% of cases so far, this has been a
>> useful QA tool. Can we wait until that's not the case to change it?
> I think an explicit die with a useful error message for the user would
> be better than the status-quo.

I agree.


Kind Regards,
Jaco