Re: [gentoo-dev] RFC: UID/GID assignment for dovecot (76)
On Thu, Aug 15, 2019 at 02:58:17PM -0400, Michael Orlitzky wrote: > On 8/7/19 5:24 AM, Eray Aslan wrote: > > I would like to reserve UID/GID 76 for dovecot (net-mail/dovecot) > > > > This id differs from what we have provided historically (97) but gid/97 > > is used by acct-group/input. So use 76 instead. > > > > This id is the same in Arch (76) but differs from Redhat (97). > > Can we please go back to posting the patches for these new packages? > Personally, I couldn't care less what integer people pick out of a hat. > I review these to prevent situations like this: For the record, it wasnt me who wrote those acct-user ebuilds. > # acct-user/postmaster > DESCRIPTION="Postmaster user" > ACCT_USER_ID=14 > ACCT_USER_HOME=/var/spool/mail > ACCT_USER_HOME_OWNER=root:mail > ACCT_USER_HOME_PERMS=03775 > ACCT_USER_GROUPS=( mail ) > > # acct-user/mail > DESCRIPTION="Mail program user" > ACCT_USER_ID=8 > ACCT_USER_HOME=/var/spool/mail > ACCT_USER_HOME_OWNER=root:mail > ACCT_USER_HOME_PERMS=03775 > ACCT_USER_GROUPS=( mail ) > > These two now need to be kept in-sync forever, because otherwise one is > going to clobber the permissions on the other's home directory. Not > having to worry about that was an explicit goal of GLEP81. > > Given that both of those users are pulled in only by net-mail/mailbase > at the moment, you probably want to set those permissions in the ebuild I dont want to set permissions in the ebuild if possible. Thats not a proper solution. Why do we need a postmaster account at all? Does anyone have a clue? > and leave those two users' home directories at the default. The > net-mail/mailbase package certainly doesn't need their home directories > set to anything in particular. (It doesn't need the user at all, but > that's probably a larger issue with mailbase.) Getting rid of mailbase is certainly another option. -- Eray
Re: [gentoo-dev] RFC: GLEP81 home directory guidelines
[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
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
Please review this patch. https://670788.bugs.gentoo.org/attachment.cgi?id=587064
Re: [gentoo-dev] [RFC] package.deprecated to mark packages deprecated and report dependencies
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
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.
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
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
