Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
> On Mon, 20 Jan 2020, Michael Orlitzky wrote: > install-qa-check.d: allow acct-user home directories under /home. Nope. As you've been told, /home is site specific and can be setup in multiple ways that are incompatible with the package manager installing things there (the only exception being baselayout creating the directory itself). Quoting FHS-3.0 again: | On large systems (especially when the /home directories are shared | amongst many hosts using NFS) it is useful to subdivide user home | directories. Subdivision may be accomplished by using subdirectories | such as /home/staff, /home/guests, /home/students, etc. So, how are you going to detect if such a scheme is used on the system, and in which subdirectory the amavis user should be placed? I also wonder why you would send this patch, when there wasn't a single voice supporting your proposition in the other thread and several opposing ones. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 2/2] install-qa-check.d: allow acct-user home directories under /home.
On Sun, 2020-01-19 at 22:43 -0500, Michael Orlitzky wrote:
> In rare cases, a system user will need a real home directory to store
> per-user configuration data and/or be accessed interactively by a
> human being. In those cases, /home/${username} is an appropriate place
> for the user's home directory. Using /home is allowed and encouraged
> by the FHS, and there are no real technical obstacles to it aside from
> an install-time QA warning about the path.
>
> Before GLEP81, the efficacy of this check was unarguable. With
> enewuser, you could still set a user's home directory to a location
> under /home, but the lack of a "keepdir" meant that it would fly under
> the radar during the QA check. As a result, the QA check would only
> flag truly problematic files. With GLEP81, however, an implementation
> detail leads this check to flag the user's home directory.
>
> This commit makes an exception for the home directory /home/${PN}
> itself, and the /home/${PN}/.keep* file it contains. This lets us
> migrate existing user.eclass ebuilds to GLEP81 without triggering a
> new QA warning on a dummy file.
>
> This will be useful in at least two real situations:
>
> * The "amavis" user exists to launch the amavisd daemon, but much of
> the configuration for that user is created in $HOME by a human who
> is logged in as "amavis" interactively. This is user data by any
> definition, and should be stored in /home/amavis rather than
> dumping it in the daemon's working directory.
>
> * The "spamd" user gets its SpamAssassin configuration the same way
> local users do in a traditional UNIX mail setup: by reading it out
> of $HOME. This is user data, even though it happens to affect the
> daemon. With user.eclass, /home/spamd is already used as the home
> directory. When migrating to GLEP81, we should not break existing
> systems and force a migration just to avoid an old warning.
>
> There are other potential uses as well. If I want to share (real
> human) user accounts across multiple Gentoo installs per the design of
> GLEP81, then I can do that with acct-user packages in an overlay. The
> user packages ensure that the same UIDs and GIDs get used on every
> system, but if I do this with my "mjo" account, I'm going to want
> /home/mjo to be my home directory. There's nothing wrong with that,
> so we shouldn't warn about it.
> ---
> metadata/install-qa-check.d/08gentoo-paths | 27 ++
> 1 file changed, 27 insertions(+)
>
> diff --git a/metadata/install-qa-check.d/08gentoo-paths
> b/metadata/install-qa-check.d/08gentoo-paths
> index 5161aef9922..ab9bd64d0e0 100644
> --- a/metadata/install-qa-check.d/08gentoo-paths
> +++ b/metadata/install-qa-check.d/08gentoo-paths
> @@ -19,6 +19,10 @@ gentoo_path_check() {
> boot dev etc opt srv usr var
> )
>
> + # We make an exception and allow acct-user packages to install to
> + # /home in rare circumstances.
> + [[ "${CATEGORY}" == "acct-user" ]] && allowed_paths_toplevel+=( home )
> +
> # directories in /usr which can be installed to by ebuilds
> # /usr/games is not included as it is banned nowadays
> local allowed_paths_usr=(
> @@ -61,6 +65,29 @@ gentoo_path_check() {
> fi
> done
>
> + # Normally ebuilds should not install anything under /home. If this
> + # is a GLEP81 user package, however, we make an exception for the
> + # user's home directory itself and the ".keep" file within it. This
> + # allows GLEP81 user packages to have home directories under /home,
> + # which can be useful if the account is meant to be used by a human
> + # to store configuration data or run maintenance tasks.
> + if [[ "${CATEGORY}" == "acct-user" ]]; then
> + local f found=()
> + while read -r -d '' f; do
> + found+=( "${f}" )
> + done < <(find -L "${ED%/}/home" \
> + -mindepth 1 \
> + -maxdepth 2 \
> + ! -path "${ED%/}/home/${PN}" \
> + ! -path "${ED%/}/home/${PN}/.keep*" \
> + -print0)
> +
> + if [[ ${found[@]} ]]; then
> + # mimic the output for non-acct-user packages.
> + bad_paths+=( "/home" )
> + fi
> + fi
> +
> ${shopt_save}
>
> # report
NAK. /home belongs to paths that are deliberately left for sysadmin to
manage and use for real (read: human) users. 'Rare cases' are no
justification to abuse those paths, especially that there is no
technical reason not to use /var (or /srv) as intended for system users.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/2] install-qa-check.d: disallow "nix" and "gnu" as top-level paths.
On Sun, 2020-01-19 at 22:43 -0500, Michael Orlitzky wrote:
> These exceptions were made for the sys-apps/nix and sys-apps/guix
> packages that are no longer in the tree.
> ---
> metadata/install-qa-check.d/08gentoo-paths | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/metadata/install-qa-check.d/08gentoo-paths
> b/metadata/install-qa-check.d/08gentoo-paths
> index e6cd7e67442..5161aef9922 100644
> --- a/metadata/install-qa-check.d/08gentoo-paths
> +++ b/metadata/install-qa-check.d/08gentoo-paths
> @@ -17,8 +17,6 @@ gentoo_path_check() {
> local allowed_paths_toplevel=(
> "${allowed_common_dirs[@]}"
> boot dev etc opt srv usr var
> - nix # sys-apps/nix, bug #670902
> - gnu # sys-apps/guix, bug #670902
> )
>
> # directories in /usr which can be installed to by ebuilds
Oh, were they removed already? In that case LGTM.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP81 and /home
On 1/19/20 10:40 PM, Rich Freeman wrote: > On Sun, Jan 19, 2020 at 10:16 PM Michael Orlitzky wrote: >> >> This is retarded, stop wasting my time. >> > > There is nothing retarded about shared /home directories. They're > pretty common in the real world. > What's retarded is copy/pasting words from last week's buzzword bingo as if they're valid reasons to not use /home for home directories. LUKS is a thing, but you don't use it. CIFS is a thing, but you don't use it. Shared home directories are a thing, but you don't use it. Give me one real example of how any of these things cause a problem and I'll change my stance. I don't have a special emotional attachment to /home. I think it's where this stuff should go because (a) home directories are what /home is for, and (b) it doesn't cause any other problems. If (b) isn't true, you win.
[gentoo-dev] [PATCH 1/2] install-qa-check.d: disallow "nix" and "gnu" as top-level paths.
These exceptions were made for the sys-apps/nix and sys-apps/guix
packages that are no longer in the tree.
---
metadata/install-qa-check.d/08gentoo-paths | 2 --
1 file changed, 2 deletions(-)
diff --git a/metadata/install-qa-check.d/08gentoo-paths
b/metadata/install-qa-check.d/08gentoo-paths
index e6cd7e67442..5161aef9922 100644
--- a/metadata/install-qa-check.d/08gentoo-paths
+++ b/metadata/install-qa-check.d/08gentoo-paths
@@ -17,8 +17,6 @@ gentoo_path_check() {
local allowed_paths_toplevel=(
"${allowed_common_dirs[@]}"
boot dev etc opt srv usr var
- nix # sys-apps/nix, bug #670902
- gnu # sys-apps/guix, bug #670902
)
# directories in /usr which can be installed to by ebuilds
--
2.24.1
[gentoo-dev] [PATCH 2/2] install-qa-check.d: allow acct-user home directories under /home.
In rare cases, a system user will need a real home directory to store
per-user configuration data and/or be accessed interactively by a
human being. In those cases, /home/${username} is an appropriate place
for the user's home directory. Using /home is allowed and encouraged
by the FHS, and there are no real technical obstacles to it aside from
an install-time QA warning about the path.
Before GLEP81, the efficacy of this check was unarguable. With
enewuser, you could still set a user's home directory to a location
under /home, but the lack of a "keepdir" meant that it would fly under
the radar during the QA check. As a result, the QA check would only
flag truly problematic files. With GLEP81, however, an implementation
detail leads this check to flag the user's home directory.
This commit makes an exception for the home directory /home/${PN}
itself, and the /home/${PN}/.keep* file it contains. This lets us
migrate existing user.eclass ebuilds to GLEP81 without triggering a
new QA warning on a dummy file.
This will be useful in at least two real situations:
* The "amavis" user exists to launch the amavisd daemon, but much of
the configuration for that user is created in $HOME by a human who
is logged in as "amavis" interactively. This is user data by any
definition, and should be stored in /home/amavis rather than
dumping it in the daemon's working directory.
* The "spamd" user gets its SpamAssassin configuration the same way
local users do in a traditional UNIX mail setup: by reading it out
of $HOME. This is user data, even though it happens to affect the
daemon. With user.eclass, /home/spamd is already used as the home
directory. When migrating to GLEP81, we should not break existing
systems and force a migration just to avoid an old warning.
There are other potential uses as well. If I want to share (real
human) user accounts across multiple Gentoo installs per the design of
GLEP81, then I can do that with acct-user packages in an overlay. The
user packages ensure that the same UIDs and GIDs get used on every
system, but if I do this with my "mjo" account, I'm going to want
/home/mjo to be my home directory. There's nothing wrong with that,
so we shouldn't warn about it.
---
metadata/install-qa-check.d/08gentoo-paths | 27 ++
1 file changed, 27 insertions(+)
diff --git a/metadata/install-qa-check.d/08gentoo-paths
b/metadata/install-qa-check.d/08gentoo-paths
index 5161aef9922..ab9bd64d0e0 100644
--- a/metadata/install-qa-check.d/08gentoo-paths
+++ b/metadata/install-qa-check.d/08gentoo-paths
@@ -19,6 +19,10 @@ gentoo_path_check() {
boot dev etc opt srv usr var
)
+ # We make an exception and allow acct-user packages to install to
+ # /home in rare circumstances.
+ [[ "${CATEGORY}" == "acct-user" ]] && allowed_paths_toplevel+=( home )
+
# directories in /usr which can be installed to by ebuilds
# /usr/games is not included as it is banned nowadays
local allowed_paths_usr=(
@@ -61,6 +65,29 @@ gentoo_path_check() {
fi
done
+ # Normally ebuilds should not install anything under /home. If this
+ # is a GLEP81 user package, however, we make an exception for the
+ # user's home directory itself and the ".keep" file within it. This
+ # allows GLEP81 user packages to have home directories under /home,
+ # which can be useful if the account is meant to be used by a human
+ # to store configuration data or run maintenance tasks.
+ if [[ "${CATEGORY}" == "acct-user" ]]; then
+ local f found=()
+ while read -r -d '' f; do
+ found+=( "${f}" )
+ done < <(find -L "${ED%/}/home" \
+ -mindepth 1 \
+ -maxdepth 2 \
+ ! -path "${ED%/}/home/${PN}" \
+ ! -path "${ED%/}/home/${PN}/.keep*" \
+ -print0)
+
+ if [[ ${found[@]} ]]; then
+ # mimic the output for non-acct-user packages.
+ bad_paths+=( "/home" )
+ fi
+ fi
+
${shopt_save}
# report
--
2.24.1
[gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
It's late and I'm sure this is buggy, but just complaining about it isn't getting me anywhere. Michael Orlitzky (2): install-qa-check.d: disallow "nix" and "gnu" as top-level paths. install-qa-check.d: allow acct-user home directories under /home. metadata/install-qa-check.d/08gentoo-paths | 29 -- 1 file changed, 27 insertions(+), 2 deletions(-) -- 2.24.1
Re: [gentoo-dev] GLEP81 and /home
On Sun, Jan 19, 2020 at 10:16 PM Michael Orlitzky wrote:
>
> This is retarded, stop wasting my time.
>
There is nothing retarded about shared /home directories. They're
pretty common in the real world.
> >> I've already got responses from two QA members. This thread is pretty
> >> hard to miss.
> >
> > Well, then why go posting stuff like "guess we'll be triggering a
> > warning after all?"
>
> If these two things are logically connected, I don't see it.
If you're working with QA to change the QA checks, then you won't be
triggering warnings.
> >> I'm working on a patch for the install-qa-check.d check
> >> and I'm sure I'll get more when I post it.
> >
> > Are you just allowing it to not create the directory, or are we
> > considering patching it to allow creating stuff under /home? It would
> > seem that the policy would also need updating in that case, but
> > probably not the former.
>
> The patch will make an exception for acct-user packages only; for /home,
> /home/${PN}, and /home/${PN}/.keep*. In other words, it makes things
> work exactly how they did before the GLEP81 eclass started keepdir'ing
> the home directory.
IMO this isn't the right direction to go in, but we can always put it
on the council agenda. Maintaining the status quo (pre-QA-check) in
the interim isn't unreasonable, nor is keeping your package behavior
as it is for now. Obviously this issue has been around for some time.
I realize that you didn't invent it.
I guess this is the sort of thing that people will tend to disagree
on. At least Gentoo doesn't force this nonsense down my throat. :)
--
Rich
Re: [gentoo-dev] GLEP81 and /home
On 1/19/20 9:52 PM, Rich Freeman wrote:
>>
>> Fantasy scenarios again. I'm not going to debunk a system that you just
>> thought up and that has never existed. Why don't you find one person who
>> actually does this, and see if it bothers him if we create a home
>> directory under /home where it belongs?
>
> Uh, I'm pretty confident that nothing in my /home is owned by a UID
> under 1000, or has an ACL referencing such a UID. I just checked with
> myself and I don't want you creating directories in /home.
This is retarded, stop wasting my time.
>>>
>>> I mean, would it kill you to just talk to QA first?
>>
>> I've already got responses from two QA members. This thread is pretty
>> hard to miss.
>
> Well, then why go posting stuff like "guess we'll be triggering a
> warning after all?"
If these two things are logically connected, I don't see it.
>
>> I'm working on a patch for the install-qa-check.d check
>> and I'm sure I'll get more when I post it.
>
> Are you just allowing it to not create the directory, or are we
> considering patching it to allow creating stuff under /home? It would
> seem that the policy would also need updating in that case, but
> probably not the former.
>
The patch will make an exception for acct-user packages only; for /home,
/home/${PN}, and /home/${PN}/.keep*. In other words, it makes things
work exactly how they did before the GLEP81 eclass started keepdir'ing
the home directory.
Re: [gentoo-dev] GLEP81 and /home
On Sun, Jan 19, 2020 at 8:51 PM Michael Orlitzky wrote: > > On 1/19/20 8:20 PM, Rich Freeman wrote: > > 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. > > Fantasy scenarios again. I'm not going to debunk a system that you just > thought up and that has never existed. Why don't you find one person who > actually does this, and see if it bothers him if we create a home > directory under /home where it belongs? Uh, I'm pretty confident that nothing in my /home is owned by a UID under 1000, or has an ACL referencing such a UID. I just checked with myself and I don't want you creating directories in /home. This really seems like it has the potential to create a mess for anybody using LUKS-encrypted home directories, stuff mounted from CIFS, and so on. While I personally don't do either it seems fairly mainstream, and I could eventually see myself using it more once better supported on Gentoo (such as when systemd-homed is more mainstream). > > 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? > > I've already got responses from two QA members. This thread is pretty > hard to miss. Well, then why go posting stuff like "guess we'll be triggering a warning after all?" > I'm working on a patch for the install-qa-check.d check > and I'm sure I'll get more when I post it. Are you just allowing it to not create the directory, or are we considering patching it to allow creating stuff under /home? It would seem that the policy would also need updating in that case, but probably not the former. -- Rich
Re: [gentoo-dev] GLEP81 and /home
On 1/19/20 8:20 PM, Rich Freeman wrote: > 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. Fantasy scenarios again. I'm not going to debunk a system that you just thought up and that has never existed. Why don't you find one person who actually does this, and see if it bothers him if we create a home directory under /home where it belongs? > 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? I've already got responses from two QA members. This thread is pretty hard to miss. I'm working on a patch for the install-qa-check.d check and I'm sure I'll get more when I post it.
Re: [gentoo-dev] GLEP81 and /home
On Sun, Jan 19, 2020 at 4:00 PM Michael Orlitzky 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 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
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-01-19 23:59 UTC
dev-util/obs-service-rearchive20200115-18:39 zlogene 55e3a382db0 dev-util/obs-service-recompress 20200115-18:39 zlogene 55e3a382db0 dev-util/obs-service-set_version 20200115-18:39 zlogene 55e3a382db0 dev-util/obs-service-source_validator 20200115-18:39 zlogene 55e3a382db0 dev-util/obs-service-tar_scm 20200115-18:39 zlogene 55e3a382db0 dev-util/obs-service-update_source20200115-18:39 zlogene 55e3a382db0 dev-util/obs-service-verify_file 20200115-18:39 zlogene 55e3a382db0 dev-util/osc 20200115-18:39 zlogene 55e3a382db0 dev-util/suse-build 20200115-18:39 zlogene 55e3a382db0 media-gfx/tic98 20200114-16:19 mgorny 802a21d2a4e media-plugins/vdr-console 20200115-21:02 hd_brummy 02395964f19 media-sound/vitunes 20200114-16:18 mgorny 98b0f788050 sci-electronics/oregano 20200114-16:22 mgorny a79f3b0c152 Additions: acct-group/amule 20191226-11:32 juippis 0e7675b43f2 acct-group/clamav 20200117-18:27 mjo 41bc9e952c9 acct-group/nagios 20200115-15:41 mjo f6d2729464f acct-user/amule 20191226-11:33 juippis 358954bc204 acct-user/clamav 20200117-18:30 mjo 6623b85500d acct-user/ippl20200118-17:35 soap 70a1fd3fa09 acct-user/nagios 20200115-15:49 mjo b507df7f76d app-crypt/jitterentropy-rngd 20200115-08:35 tamiko 98bda6b93d1 app-text/xhtml11 20200117-05:43 mgorny 810e8db30e0 dev-libs/boxfort 20200110-11:15 juippis a72bee57426 dev-libs/kpeoplevcard 20200119-16:40 asturm fdfc1b0dff2 dev-python/casttube 20200114-17:30 prometheanfire dacd9fb51d6 dev-python/ifaddr 20200114-17:14 prometheanfire f765a65bff3 dev-python/pychromecast 20200114-17:30 prometheanfire 7afdd889287 dev-python/python-jsonrpc-server 20191227-15:58 juippis e190d875bee dev-python/python-language-server 20191227-15:58 juippis 18e314a2af0 dev-python/python-xmp-toolkit 20200113-14:40 grozin 9426de1601d dev-python/wurlitzer 20191217-11:00 juippis fe40e97bc43 media-fonts/jetbrains-mono20200117-06:22 juippis 1b3f24853bf sci-libs/libbraiding 20200115-01:45 mjo 78db3420a50 sys-process/minicoredumper20200114-03:47 gyakovlev b80df23c42a -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: app-editors/emacs-vcs,removed,ulm,20200117-17:06,cb3eccbbd9b media-plugins/vdr-console,removed,hd_brummy,20200115-21:02,02395964f19 dev-util/obs-service-cpanspec,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-download_files,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-download_src_package,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-download_url,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-extract_file,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-format_spec_file,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-generator_driver_update_disk,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-git_tarballs,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-github_tarballs,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-meta,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-rearchive,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-recompress,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-set_version,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-source_validator,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-tar_scm,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-update_source,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/obs-service-verify_file,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/osc,removed,zlogene,20200115-18:39,55e3a382db0 dev-util/suse-build,removed,zlogene,20200115-18:39,55e3a382db0 dev-ml/ANSITerminal,removed,mgorny,20200114-16:25,e73cdb8ec30 dev-ml/OCaml-ImageMagick
[gentoo-dev] CFLAGS=-fno-common related breakage is incoming
> What is happening?
gcc-10 is coming soon. It will be more disruptive than gcc-9.
One of the major changes is the switch from C{,XX}FLAGS=-fcommon
to C{,XX}FLAGS=-fno-common by default: https://gcc.gnu.org/PR85678
It's a planned change and not a gcc regression. It will expose some
warts on old code and unblock minor optimisations accessing globals.
The change has already happened in gcc trunk.
> Is my package affected? Should I do anything?
You can check proactively if your packages are affected.
Add -fno-common to your make.conf's C{,XX}FLAGS and
see if things still build.
The typical symptom is a linker failure on multiple definitions
for some global variable:
ld: a.o:(.bss+0x0): multiple definition of `a'; main.o:(.data+0x0): first
defined here
> How to fix it?
https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common contains
some examples. Ideally code will need a few 'extern' additions and maybe
moving variable definitions.
Example of proposed openrc fix:
https://github.com/OpenRC/openrc/pull/348
Adding 'append-flags -fcommon' might work as a temporary workaround.
> Can I help?
Glad you asked! We will need to gather failed packages and fix them
upstream and downstream. Here is what you can do:
1. Add -fno-common to your make.conf's C{,XX}FLAGS
2. Build packages you maintain
3. Fix a bug upstream (or report a failure).
4. Pull a fix downstream (or file a bug and add it to the tracker).
> What is already known to be broken? Can I look at example fixes?
See https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common
for an artificial example.
Gentoo tracker bug of known issues:
https://bugs.gentoo.org/705764
15 bugs so far.
SUSE tracker bug of known issues:
https://bugzilla.suse.com/show_bug.cgi?id=1160244
95 bugs so far. A good source of packages to check against the
ones you care about.
> What does -fcommon do?
Look up -fcommon in https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
> I have no idea why my package broke. The error does not make sense.
Feel free to CC toolchain@ on a bug you observe and we'll try to sort it out.
--
Sergei
[gentoo-dev] Last rites: media-sound/glmix
# Andreas Sturmlechner (2020-01-19) # Ancient, last release in 2006, blocks x11-libs/gtkglext cleanup # Masked for removal in 30 days. media-sound/glmix signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP81 and /home
On 1/19/20 4:00 PM, Michael Orlitzky wrote: > > If I was willing to introduce a QA warning, this thread would have been > a lot shorter =P > 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.
Re: [gentoo-dev] New QA Policy Guide
On Sun, Jan 19, 2020 at 12:31:52PM +0100, Michał Górny wrote: > Hello, > > In the light of the recent misunderstandings, I have started working > on an official Policy Guide [1]. The Guide is meant to provide > a focused list of officially approved QA policies, along with their > rationale and any other useful information. > > This should supplement devmanual [2] with clear information on what is > enforceable policy, and what is merely a suggestion (or possibly > outdated information, which is a common problem for devmanual). > > The current document contents were approved by the QA project. However, > it is by no means complete. Further existing policies (as well as new > policies) will be documented there as they are approved by QA team. Why are we creating another guide instead of just consolidating everything in the devmanual? My understanding of things has been that the devmanual is the location of official qa policies, but now we have devmanual, this new guide and https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies > > The sources are stored in proj/policy-guide.git [3]. If you wish to > submit your own changes, you can either use the 'Policy Guide' bugzilla > component [4] and/or GitHub mirror [5]. I also agree with ulm et al wrt any official discussion wrt changes needing to happen on bugzilla. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] GLEP81 and /home
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. >> We've talked this to death. Barring any new evidence, /home still seems >> like the best place for these, and I don't want to put them in the wrong >> spot (forcing users to migrate) just to appease a QA warning from before >> GLEP81 was a thing. > > Well, great, then by all means ask QA for a policy exception. Not my > place to yell at you if you don't, but don't be surprised if somebody > else does... > I'm not going to violate the policy, I'm going to delete the keepdir file from $D. Then everything is back to normal. If I was willing to introduce a QA warning, this thread would have been a lot shorter =P
Re: [gentoo-dev] GLEP81 and /home
On 1/19/20 2:32 PM, Alec Warner wrote: > > Earlier you wrote: > > * The daemon DOES NOT need a home directory for its user. > * I DO NOT want to install anything to anyone's home directory. > * With respect to user.eclass, I'm proposing that /home be treated > EXACTLY THE SAME as it always has been. > --- > > So my question is "why not leave the homedir unset, or set it to /dev/null?" > The claim is that the daemon doesn't need a home directory, so why are > we trying to make one? > Ah, good question. As the de facto no-homedir police, even I think this case warrants an exception. Technically, the daemon's user does not need a home directory. But almost everyone that uses amavis will want to combine it with one of these programs that looks in $HOME. We could install the user with no homedir, and make the people who need it override the acct-user ebuild in an overlay, but that's a pain in the butt. Since the common case will utilize a home directory, I'd rather pick one decent location upstream, and not have 99% of users define one ad-hoc in an overlay. The reason I'm being so annoying is because it's important to get the location right. Every time the user package is reinstalled, its homedir gets reset. So it's non-trivial to override, and can't really be changed in an ebuild (usermod fails if the user is running a process).
Re: [gentoo-dev] New QA Policy Guide
On Sun, 2020-01-19 at 19:34 +, Robin H. Johnson wrote: > On Sun, Jan 19, 2020 at 12:31:52PM +0100, Michał Górny wrote: > > Hello, > > > > In the light of the recent misunderstandings, I have started working > > on an official Policy Guide [1]. The Guide is meant to provide > > a focused list of officially approved QA policies, along with their > > rationale and any other useful information. > > > > This should supplement devmanual [2] with clear information on what is > > enforceable policy, and what is merely a suggestion (or possibly > > outdated information, which is a common problem for devmanual). > Thank you for this this! > > I have some requests for improvement & content. > > 1. Stable identifiers for policy: > Assign ID numbers or stable identifying slugs to each policy and use > them for referencing from all tooling in future. Also makes searching > MUCH easier. > > The ID variant might be 'GPN' (string prefix, followed by numeric > value) > > The slug variant (modelled after Rubocop) might be > "Ebuild:CodingStyle" > > My personal preference would be the ID variant, after seeing Rubocop > have to rename identifying slugs slowly & painfully over many years; > however the slug variant is MUCH better for usability > > 2. Usability/viewing: > 2.1. DT-squashed: > Please fix the CSS rendering of the . My chrome window is 1198 x > 1870 (screen is portrait version 1920x1200). > Screenshot: > https://dev.gentoo.org/~robbat2/.private/20200119-policy-guide-render-window.png > > 2.2. Whitespace: > The left column has a LOT of wasted whitespace. > > 2.3 Navigation: > Please add next/previous links on the top AND bottom of each page. > Ok, I am sorry. I've sent this mail with the conviction that new version was deployed but I've been informed that it didn't. I've manually updated the site now, and it should show the new theme after refresh. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New QA Policy Guide
On Sun, 2020-01-19 at 19:44 +0100, Haelwenn (lanodan) Monnier wrote: > Thanks a lot for this policy guide, finally there is a good documentation > on them. > > I found one issue with it though, on pages like other-metadata.html and > keywords.html the links are too large and squish the dt elements, one way > I found to fix it is by adding `word-break: break-all` to a.reference but > maybe it should use a selector closer to the root. > Ok, I am sorry. I've sent this mail with the conviction that new version was deployed but I've been informed that it didn't. I've manually updated the site now, and it should show the new theme after refresh. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP81 and /home
On Sun, Jan 19, 2020 at 2:27 PM Michael Orlitzky wrote: > > On 1/19/20 2:02 PM, Rich Freeman wrote: > > > >> If you're sharing /home, you also have to be sharing user accounts, > >> unless you want everyone to be assigned a random set of files. > > > > I imagine that most people setting up something like this would only > > be sharing high-value UIDs (>1000 in our case). There is no need for > > postfix on your Gentoo box and postfix on your Debian box to have the > > same UID. You wouldn't be sshing from postfix on the one to postfix > > on the other and expecting to have the same home directory contents. > > > > You can't do that. If you're going to mount files from one system onto > another system, using only an integer <--> username mapping as your > access control mechanism, then you'd better be damn sure that those > integers and usernames match on all systems. Otherwise I might wind up > sharing /home/mjo to rich0 because the "mjo" and "rich0" groups both > have gid 1000 locally. 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. > We've talked this to death. Barring any new evidence, /home still seems > like the best place for these, and I don't want to put them in the wrong > spot (forcing users to migrate) just to appease a QA warning from before > GLEP81 was a thing. Well, great, then by all means ask QA for a policy exception. Not my place to yell at you if you don't, but don't be surprised if somebody else does... -- Rich
Re: [gentoo-dev] New QA Policy Guide
On Sun, Jan 19, 2020 at 2:32 PM Kent Fredric wrote: > > Having a discussion at a bar, and you making a commit as a result is > one thing, but if I discovered a bug, and then only told you about it > at the bar, that would be possibly bad, because there's no guarantee > that the bug is communicated sufficient to ensure it gets addressed, > and you may go home at the end of the night and entirely forget the bug > existed, and people could continue to suffer it, and potentially > neglect to report it as well. ( End users are substantially less likely > to file bugs, IME ) > > When I mention bugs to people on IRC, I often follow up with "Would you > like me to file a bug?". > > Often, the answer is "yes". > > The crux of the matter being bugs that exist, and are communicated > outside the core bug tracker, weaken the assurance that it will be seen > and fixed, which amounts to a negative thing. Oh, I absolutely agree with this. My point is that right now we have no policy that requires bugs to be filed. And hence stuff that happens on github really is no different than your case of stuff happening in a bar. I can't speak for the QA repo, but don't we have a bot that notices open pull requests for the main repo mirror on github which are missing bug references to post notices to this effect? When this started happening I think a lot of the concerns were reduced. I mean, like was already mentioned, if there were a gitlab repo or whatever being hosted a lot of this might become moot. We're just not there yet. I'm not sure if the Foundation has considered approaching gitlab.com about hosting. Granted, that isn't their FOSS product, but I suspect the repos could be exported and imported into the FOSS product as a contingency. I have it on good authority from somebody who works there that their proprietary hosted product is identical to the FOSS one aside from the proprietary modules, so as long as you avoid the latter it should be the same thing. If they're willing to donate or offer cheaper hosting it might give us the benefits of the FOSS repository while avoiding the hassles of hosting Ruby or whatever it is written in. -- Rich
Re: [gentoo-dev] New QA Policy Guide
On Sun, 2020-01-19 at 19:34 +, Robin H. Johnson wrote: > On Sun, Jan 19, 2020 at 12:31:52PM +0100, Michał Górny wrote: > > Hello, > > > > In the light of the recent misunderstandings, I have started working > > on an official Policy Guide [1]. The Guide is meant to provide > > a focused list of officially approved QA policies, along with their > > rationale and any other useful information. > > > > This should supplement devmanual [2] with clear information on what is > > enforceable policy, and what is merely a suggestion (or possibly > > outdated information, which is a common problem for devmanual). > Thank you for this this! > > I have some requests for improvement & content. > > 1. Stable identifiers for policy: > Assign ID numbers or stable identifying slugs to each policy and use > them for referencing from all tooling in future. Also makes searching > MUCH easier. > > The ID variant might be 'GPN' (string prefix, followed by numeric > value) > > The slug variant (modelled after Rubocop) might be > "Ebuild:CodingStyle" > > My personal preference would be the ID variant, after seeing Rubocop > have to rename identifying slugs slowly & painfully over many years; > however the slug variant is MUCH better for usability I was wondering about this. However, wouldn't permalinks be good enough? Each section has its own anchor, and it makes them immediately useful for seeing the policy in question without having to resort to searching. > 2. Usability/viewing: > 2.1. DT-squashed: > Please fix the CSS rendering of the . My chrome window is 1198 x > 1870 (screen is portrait version 1920x1200). > Screenshot: > https://dev.gentoo.org/~robbat2/.private/20200119-policy-guide-render-window.png > > 2.2. Whitespace: > The left column has a LOT of wasted whitespace. > > 2.3 Navigation: > Please add next/previous links on the top AND bottom of each page. Please file theme-related bugs at: https://github.com/mmagorsc/tyrian_sphinx_theme > > 2.4. Search results: > Many two-letter search terms return nothing, "QA", "QT" I suspect this is Sphinx's limitation and I'm not qualified to deal with it. I'd suggest using index + in-page search. That said, I'm open to pull requests / patches to improve index. > 3. Content requests: > 3.1. > Cover policy around ELF binary dependency verification (this related to > the ebuild maintainer quiz question "How can you verify an ebuild has > correct run time dependencies (RDEPEND) for all installed binaries?" > > 3.2. > Cover policy around making sure that ALL licenses around installed > data being listed in the LICENSE variable, which is becoming > increasingly important for Rust & Go where the output binaries are > usually static, and many licenses might be included via dependencies > on the codebase. Could you file bugs for that (on Bugzilla)? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP81 and /home
On Sun, Jan 19, 2020 at 10:49:10AM -0500, Michael Orlitzky wrote: > > That bug appears to be restricted. Perhaps it is embargoed? If not, > > then it probably shouldn't be restricted, especially if already fixed > > and GLSA'ed (and if it wasn't GLSA'ed then it isn't fixed, not that > > this has anything to do with you most likely). > It's embargoed because security-audit@ goes to /dev/null, but the bug is > already fixed. (If anyone can un-embargo my other 50 ancient security > bugs, just let me know who to bribe.) Please file a bug to infra with the list of old security embargoed bugs, and we can help you get them fixed (probably by helping you review them first). -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] New QA Policy Guide
On Sun, Jan 19, 2020 at 12:31:52PM +0100, Michał Górny wrote: > Hello, > > In the light of the recent misunderstandings, I have started working > on an official Policy Guide [1]. The Guide is meant to provide > a focused list of officially approved QA policies, along with their > rationale and any other useful information. > > This should supplement devmanual [2] with clear information on what is > enforceable policy, and what is merely a suggestion (or possibly > outdated information, which is a common problem for devmanual). Thank you for this this! I have some requests for improvement & content. 1. Stable identifiers for policy: Assign ID numbers or stable identifying slugs to each policy and use them for referencing from all tooling in future. Also makes searching MUCH easier. The ID variant might be 'GPN' (string prefix, followed by numeric value) The slug variant (modelled after Rubocop) might be "Ebuild:CodingStyle" My personal preference would be the ID variant, after seeing Rubocop have to rename identifying slugs slowly & painfully over many years; however the slug variant is MUCH better for usability 2. Usability/viewing: 2.1. DT-squashed: Please fix the CSS rendering of the . My chrome window is 1198 x 1870 (screen is portrait version 1920x1200). Screenshot: https://dev.gentoo.org/~robbat2/.private/20200119-policy-guide-render-window.png 2.2. Whitespace: The left column has a LOT of wasted whitespace. 2.3 Navigation: Please add next/previous links on the top AND bottom of each page. 2.4. Search results: Many two-letter search terms return nothing, "QA", "QT" 3. Content requests: 3.1. Cover policy around ELF binary dependency verification (this related to the ebuild maintainer quiz question "How can you verify an ebuild has correct run time dependencies (RDEPEND) for all installed binaries?" 3.2. Cover policy around making sure that ALL licenses around installed data being listed in the LICENSE variable, which is becoming increasingly important for Rust & Go where the output binaries are usually static, and many licenses might be included via dependencies on the codebase. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP81 and /home
On Sun, Jan 19, 2020 at 11:28 AM Michael Orlitzky wrote: > On 1/19/20 2:19 PM, Alec Warner wrote: > > > > All I want to do is *set* a user's home directory to /home/foo. > > > > Why wouldn't you set the homedirectory to /dev/null then? > > > > Because /dev/null is not /home/foo? Is this a trick question? =) > > Ahh quoting, I'll try with more context ;) Earlier you wrote: * The daemon DOES NOT need a home directory for its user. * I DO NOT want to install anything to anyone's home directory. * With respect to user.eclass, I'm proposing that /home be treated EXACTLY THE SAME as it always has been. --- So my question is "why not leave the homedir unset, or set it to /dev/null?" The claim is that the daemon doesn't need a home directory, so why are we trying to make one? -A
Re: [gentoo-dev] New QA Policy Guide
On Sun, 19 Jan 2020 13:54:33 -0500 Rich Freeman wrote: > Nothing of importance should be stored on github. > > If you and I have a conversation at a bar, and as a result you decide > to make a commit without any useful comments, and then we both retire > from the project, just as much information is lost. Its not that I'm saying that this should be forbidden, only that there is a tangible risk of lost of useful information. Having a discussion at a bar, and you making a commit as a result is one thing, but if I discovered a bug, and then only told you about it at the bar, that would be possibly bad, because there's no guarantee that the bug is communicated sufficient to ensure it gets addressed, and you may go home at the end of the night and entirely forget the bug existed, and people could continue to suffer it, and potentially neglect to report it as well. ( End users are substantially less likely to file bugs, IME ) When I mention bugs to people on IRC, I often follow up with "Would you like me to file a bug?". Often, the answer is "yes". The crux of the matter being bugs that exist, and are communicated outside the core bug tracker, weaken the assurance that it will be seen and fixed, which amounts to a negative thing. I wouldn't forbid such a thing, just make it clear that doing so is a lower standard of quality, has risks, and should come with a level of discouragement. pgp5dvxl_ePUz.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP81 and /home
On 1/19/20 2:19 PM, Alec Warner wrote: > > All I want to do is *set* a user's home directory to /home/foo. > > Why wouldn't you set the homedirectory to /dev/null then? > Because /dev/null is not /home/foo? Is this a trick question? =)
Re: [gentoo-dev] GLEP81 and /home
On 1/19/20 2:02 PM, Rich Freeman wrote: > >> If you're sharing /home, you also have to be sharing user accounts, >> unless you want everyone to be assigned a random set of files. > > I imagine that most people setting up something like this would only > be sharing high-value UIDs (>1000 in our case). There is no need for > postfix on your Gentoo box and postfix on your Debian box to have the > same UID. You wouldn't be sshing from postfix on the one to postfix > on the other and expecting to have the same home directory contents. > You can't do that. If you're going to mount files from one system onto another system, using only an integer <--> username mapping as your access control mechanism, then you'd better be damn sure that those integers and usernames match on all systems. Otherwise I might wind up sharing /home/mjo to rich0 because the "mjo" and "rich0" groups both have gid 1000 locally. > Since it is a local account, not in /home, then it would be a separate > user even if the UID is the same (or otherwise). You'd set up amavis > on each mail server. They might be running different distros. They > would be using local users. > > Don't get me wrong, it would be cleaner if POSIX users had a scope the > way that an OS like Windows does it, but it isn't a big deal if you > use high-numbered UIDs for shared users, and low-numbered UIDs for > local users. It's a huge deal. Random users/groups can access your files if the databases don't agree. The local/remote user distinction does not exist. >> Everything is fine here, this all works and has worked for 20 years. > > Sure, it works fine if you have a single host, or do nothing to share > your home directories, which I imagine is what 95% of Gentoo users do. > I doubt most Gentoo users even encrypt /home, even though this has > been standard for most of those 20 years on just about every major > distro out there. > > If a user wants to put this stuff in /home we should certainly support > that, and it would work fine if the user sets up the account properly > before installing the package. They might get a QA warning, but that > is the user's concern. We've talked this to death. Barring any new evidence, /home still seems like the best place for these, and I don't want to put them in the wrong spot (forcing users to migrate) just to appease a QA warning from before GLEP81 was a thing.
Re: [gentoo-dev] New QA Policy Guide
On Sun, 2020-01-19 at 19:44 +0100, Haelwenn (lanodan) Monnier wrote: > Thanks a lot for this policy guide, finally there is a good documentation > on them. > > I found one issue with it though, on pages like other-metadata.html and > keywords.html the links are too large and squish the dt elements, one way > I found to fix it is by adding `word-break: break-all` to a.reference but > maybe it should use a selector closer to the root. > Please report bugs at [1]. [1] https://github.com/mmagorsc/tyrian_sphinx_theme -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP81 and /home
On Sat, Jan 18, 2020 at 6:50 PM Michael Orlitzky wrote: > On 1/18/20 7:21 PM, Rich Freeman wrote: > > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote: > >> > >> But now users have to follow one more step (create /home/amavis) when > >> setting up amavisd-new. Is the QA check really assuring a quality user > >> experience here? > >> > > > > Lots of daemons need a home directory for their users, and usually > > they manage to get by in /var/lib. It really seems like a bad > > practice to start having packages creating stuff in /home. Certainly > > I don't want random daemons sticking stuff in /home, which I manage > > > > Let's restart: > > * The daemon DOES NOT need a home directory for its user. > * I DO NOT want to install anything to anyone's home directory. > * With respect to user.eclass, I'm proposing that /home be treated > EXACTLY THE SAME as it always has been. > > All I want to do is *set* a user's home directory to /home/foo. > Why wouldn't you set the homedirectory to /dev/null then? -A > > Some people want to configure amavis to launch a program like pyzor, > which uses per-user configuration files. If you want to do that, you > first log in as amavis, and run some command like > > $ pyzor discover > > which then finds some servers and creates configuration files for you in > $HOME/.pyzor. > > This is user configuration, not daemon configuration. It doesn't belong > in the daemon's working directory. In particular, you should not be > dicking around in the daemon's working directory when you run "su > amavis..." because what you're doing is irrelevant to the daemon. > > Spamassassin itself is a better example than amavis. We already set the > spamd user's home directory to /home/spamd with user.eclass. We don't > install anything there, and this works fine. If a human logs into that > account and generates some configuration in ~/.spamassassin, then it's > within the spirit of the FHS to have that data stored in /home. > > Now, with GLEP 81, we get a QA warning for that, because the eclass > installs a keepdir file there. I would like things to remain exactly as > they are, with no QA warning. Otherwise, we have to tell users to move > /home/spamd to /var/lib/spamd-home or something stupid like that. I can > think of no good reason to do so. > > > > It seems like the straightforward solution is to stick everything in > > /var/lib/amavis, and fix things so that everything has the right > > permissions regardless of install order. > > Please stop telling people to do this. Calling chown on the live > filesystem is rarely safe, and I already fixed one root exploit (bug > 630836) in the amavisd-new ebuild from the last guy who tried to adjust > wrong permissions after the fact. > > > > Another option is to have /var/lib/amavis/home and /var/lib/amavis/work. > > This is better-looking than /var/lib/amavis-home, but it's still > violating the spirit of the FHS to avoid triggering a warning on a dummy > file. > >
Re: [gentoo-dev] GLEP81 and /home
On Sun, Jan 19, 2020 at 1:37 PM Michael Orlitzky wrote: > > On 1/19/20 12:42 PM, Rich Freeman wrote: > > > > Typically you wouldn't share service accounts across multiple hosts. > > I'd think that something like amavisd is going to go on a mail server. > > You're not going to be logging into that account to do typical > > desktop-oriented functions. > > > > If you had three mail servers, you probably would want to share > > /home/mjo across all of them, but you probably wouldn't want to share > > your amavisd config across them. That is why the config goes in /etc. > > I don't see how stuff it launches would be any different. > > The stuff it launches is different because the stuff it launches is > different. SpamAssassin, for example, can be run by normal users in a > traditional UNIX mail setup. So its configuration goes in $HOME, because > that's how it works. When amavis runs spamassassin, the SA configuration > comes from $HOME, because that's how it works. Sure, I completely understand that and have no issues with it. Ditto with having some apache module running sendmail, which has some plugin which gpg signs emails, which requires a ~/.gnupg for the apache user. > If you're sharing /home, you also have to be sharing user accounts, > unless you want everyone to be assigned a random set of files. I imagine that most people setting up something like this would only be sharing high-value UIDs (>1000 in our case). There is no need for postfix on your Gentoo box and postfix on your Debian box to have the same UID. You wouldn't be sshing from postfix on the one to postfix on the other and expecting to have the same home directory contents. > And if > you're sharing user accounts, you have to start each instance of amavis > as a different user, because its configuration is per-user. That's just > the way it works. Since it is a local account, not in /home, then it would be a separate user even if the UID is the same (or otherwise). You'd set up amavis on each mail server. They might be running different distros. They would be using local users. Don't get me wrong, it would be cleaner if POSIX users had a scope the way that an OS like Windows does it, but it isn't a big deal if you use high-numbered UIDs for shared users, and low-numbered UIDs for local users. > Everything is fine here, this all works and has worked for 20 years. Sure, it works fine if you have a single host, or do nothing to share your home directories, which I imagine is what 95% of Gentoo users do. I doubt most Gentoo users even encrypt /home, even though this has been standard for most of those 20 years on just about every major distro out there. If a user wants to put this stuff in /home we should certainly support that, and it would work fine if the user sets up the account properly before installing the package. They might get a QA warning, but that is the user's concern. -- Rich
Re: [gentoo-dev] New QA Policy Guide
On Sun, Jan 19, 2020 at 1:45 PM Kent Fredric wrote: > > On Sun, 19 Jan 2020 07:08:30 -0500 > Rich Freeman wrote: > > > The official sources aren't in github. A bugzilla component is > > available, so if github goes away there is no problem and we aren't > > relying on it. > > If github goes away after bugs and PR's are filed on github, then that > historical context is lost, and may include the loss of open bugs and > open PRs, which all may still be relevant. Nothing of importance should be stored on github. If you and I have a conversation at a bar, and as a result you decide to make a commit without any useful comments, and then we both retire from the project, just as much information is lost. We don't require anybody to open a bug before making a commit today, so why would we be concerned when non-required outside documentation is stored in github? That is more information than we already require, so if it goes away nothing required by policy is lost. If we made it a policy that all commits required some kind of peer review in bugzilla, then of course we should do the same here. Right now we do not require that background for just about anything the distro does be recorded anywhere. If github's existence bothers you, then just pretend it doesn't exist - stick it in your hosts file or block it at your router. In theory it shouldn't change your Gentoo experience at all. :) -- Rich
Re: [gentoo-dev] New QA Policy Guide
On Sun, 19 Jan 2020 12:31:52 +0100 Michał Górny wrote: > Enjoy! Many thanks for making this happen. pgpkU6bOR1NU6.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New QA Policy Guide
On Sun, 19 Jan 2020 07:08:30 -0500 Rich Freeman wrote: > The official sources aren't in github. A bugzilla component is > available, so if github goes away there is no problem and we aren't > relying on it. If github goes away after bugs and PR's are filed on github, then that historical context is lost, and may include the loss of open bugs and open PRs, which all may still be relevant. Many people consider that to be a bad thing. pgpRfe3TY4eJv.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New QA Policy Guide
Thanks a lot for this policy guide, finally there is a good documentation on them. I found one issue with it though, on pages like other-metadata.html and keywords.html the links are too large and squish the dt elements, one way I found to fix it is by adding `word-break: break-all` to a.reference but maybe it should use a selector closer to the root.
Re: [gentoo-dev] GLEP81 and /home
On 1/19/20 12:42 PM, Rich Freeman wrote: > > Typically you wouldn't share service accounts across multiple hosts. > I'd think that something like amavisd is going to go on a mail server. > You're not going to be logging into that account to do typical > desktop-oriented functions. > > If you had three mail servers, you probably would want to share > /home/mjo across all of them, but you probably wouldn't want to share > your amavisd config across them. That is why the config goes in /etc. > I don't see how stuff it launches would be any different. The stuff it launches is different because the stuff it launches is different. SpamAssassin, for example, can be run by normal users in a traditional UNIX mail setup. So its configuration goes in $HOME, because that's how it works. When amavis runs spamassassin, the SA configuration comes from $HOME, because that's how it works. If you're sharing /home, you also have to be sharing user accounts, unless you want everyone to be assigned a random set of files. And if you're sharing user accounts, you have to start each instance of amavis as a different user, because its configuration is per-user. That's just the way it works. Everything is fine here, this all works and has worked for 20 years. If you have a real scenario where any of this causes a problem, I truly would like to hear it so that I don't make a mistake. But picking apart hypothetical scenarios that don't actually apply is making this thread way longer and more confusing than it has to be. > You don't really want to be using it interactively as a human per-se > any more than you interactively log in as root or any other service > account. There are rare occassions where I'll launch a shell as > apache or postfix or whatever, but that doesn't mean that you want it > to have a home in /home. You also log in as amavis to e.g. release spam from the quarantine. And postfix/apache don't need home directories at all, it's not the same. > I mean, you're still doing stuff as root. You're just not running chown. > > POSIX certainly could fix it, though whether it could do it in a > manner that doesn't break everything in existence is another matter. > For example, if POSIX just got rid of hard links many of the issues > would just go away. Hard links are a red herring. Any write or execute operation you intend to perform as root in my home directory can be subverted in a million different ways. Hard links just happen to be the stupidest one-line way to convince people of that fact. There's already a POSIX solution for changing permissions/ownership: don't do that. Set umask appropriately, and create files as the user who should own them. Then you don't have to call chown/chmod to fix the mess you just created. Running "touch foo.txt && chown mjo foo.txt" as root in a directory I control is asking for trouble, but if I run "touch foo.txt" as myself in the same directory... what am I going to do, escalate privileges to myself?
Re: [gentoo-dev] New QA Policy Guide
On Sun, 2020-01-19 at 18:50 +0100, Thomas Deutschmann wrote: > On 2020-01-19 12:46, Ulrich Mueller wrote: > > > > > > > On Sun, 19 Jan 2020, Michał Górny wrote: > > > The sources are stored in proj/policy-guide.git [3]. If you wish to > > > submit your own changes, you can either use the 'Policy Guide' bugzilla > > > component [4] and/or GitHub mirror [5]. > > > > Please, no github for official policies. We should have a permanent > > paper trail for this kind of things, which isn't guaranteed if the > > discussion would happen entirely on github. > > > > Besides, by the Social Contract we cannot rely on a non-free service > > for anything official. > > I would second that but this would also apply to devmanual. > > And at some point it will also affect contribution to Gentoo repository > at Github itself: Sure, eclass changes require ML review but sometimes > comments contain valuable information especially for the future when > someone wants to understand why an ebuild was changed that way. Valuable information belongs in comments in the ebuild or in the commit message. > That's why Debian created https://salsa.debian.org/, Fedora has > https://src.fedoraproject.org/ ... ...and Gentoo developers are doing what they do best -- talking big. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New QA Policy Guide
On 2020-01-19 12:46, Ulrich Mueller wrote: >> On Sun, 19 Jan 2020, Michał Górny wrote: > >> The sources are stored in proj/policy-guide.git [3]. If you wish to >> submit your own changes, you can either use the 'Policy Guide' bugzilla >> component [4] and/or GitHub mirror [5]. > > Please, no github for official policies. We should have a permanent > paper trail for this kind of things, which isn't guaranteed if the > discussion would happen entirely on github. > > Besides, by the Social Contract we cannot rely on a non-free service > for anything official. I would second that but this would also apply to devmanual. And at some point it will also affect contribution to Gentoo repository at Github itself: Sure, eclass changes require ML review but sometimes comments contain valuable information especially for the future when someone wants to understand why an ebuild was changed that way. That's why Debian created https://salsa.debian.org/, Fedora has https://src.fedoraproject.org/ ... -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP81 and /home
On Sun, Jan 19, 2020 at 10:49 AM Michael Orlitzky wrote:
>
> On 1/19/20 6:29 AM, Rich Freeman wrote:
> >
> > Daemons are local users. There is no guarantee that /home is a local
> > filesystem. Heck, there is no guarantee that /home is even mounted
> > when portage is running. Portage shouldn't be touching /home at all.
> > With stuff like automounted or encrypted home directories and
> > systemd-homed and so on it seems like it is even more important to
> > avoid sticking stuff in /home (and this is hardly something started by
> > systemd - stuff in /home that is non-static has been a thing for some
> > time - certainly it was happening in the 90s on some IRIX workstations
> > I used).
>
> If you're sharing /home, you're also sharing users. At that point, the
> daemon user is no longer local.
Typically you wouldn't share service accounts across multiple hosts.
I'd think that something like amavisd is going to go on a mail server.
You're not going to be logging into that account to do typical
desktop-oriented functions.
If you had three mail servers, you probably would want to share
/home/mjo across all of them, but you probably wouldn't want to share
your amavisd config across them. That is why the config goes in /etc.
I don't see how stuff it launches would be any different.
This is why /root is typically outside of /home as well.
> I like your /var/lib/amavis/{home,work} suggestion second-best, but the
> most appropriate place for the home directory of an account that will be
> used interactively by a human (even if it's also used to start a daemon)
> is under /home. For example I do want to back up that home directory,
> but I don't want to back up the working directory.
Honestly, since you're only using it for what amounts to configuration
it almost makes sense to put it in /etc, and back it up for that
reason.
You don't really want to be using it interactively as a human per-se
any more than you interactively log in as root or any other service
account. There are rare occassions where I'll launch a shell as
apache or postfix or whatever, but that doesn't mean that you want it
to have a home in /home.
> > Portage should provide a safe mechanism to fix permissions. Or we
> > should just avoid nesting user home directories inside directories
> > that will be written to by that user.
> >
> > If this is the same hard-linking concern as with tmpfiles.d then
> > somebody really just needs to fix POSIX. :) But as a workaround just
> > avoiding nesting seems like the simpler solution...
>
> Essentially yes, but hard links aren't the only problem. It's unsafe to
> do anything as root in a user-controlled directory. POSIX can't fix
> that, and that means that portage will never be able to fix permissions
> (or do anything else) within a user-controlled directory safely.
I mean, you're still doing stuff as root. You're just not running chown.
POSIX certainly could fix it, though whether it could do it in a
manner that doesn't break everything in existence is another matter.
For example, if POSIX just got rid of hard links many of the issues
would just go away.
Obviously if the problem had a simple solution it would have been
implemented by now.
BTW, thanks to the recent QA post I can at least point you at
documentation for your issue. Per the article if you want to change
it the procedure is to ask QA for an exception or change in policy,
and if you don't like the answer go to Council...
https://projects.gentoo.org/qa/policy-guide/filesystem.html#installation-paths
--
Rich
Re: [gentoo-dev] GLEP81 and /home
On 1/19/20 6:29 AM, Rich Freeman wrote:
>
> Daemons are local users. There is no guarantee that /home is a local
> filesystem. Heck, there is no guarantee that /home is even mounted
> when portage is running. Portage shouldn't be touching /home at all.
> With stuff like automounted or encrypted home directories and
> systemd-homed and so on it seems like it is even more important to
> avoid sticking stuff in /home (and this is hardly something started by
> systemd - stuff in /home that is non-static has been a thing for some
> time - certainly it was happening in the 90s on some IRIX workstations
> I used).
If you're sharing /home, you're also sharing users. At that point, the
daemon user is no longer local. The rest, with all due respect, is FUD.
This is a home directory for an account that a human being will log
into, where he interactively creates per-user configuration files. If
that doesn't go in /home, what does?
If you're sharing $HOME for all of your users, why wouldn't you want to
share $HOME for this user? Trying to "hide" this one particular home
directory is second-guessing the administrator.
> You don't just want to "set" it. You want to create the directory,
> which is modifying the filesystem (otherwise, why have a .keepdir?).
> And setting a home directory to something that doesn't exist doesn't
> seem like an improvement unless it is /dev/null.
>
> I get though that the daemon itself doesn't use the home directory,
> and that you just want it for configuring other stuff it might launch.
The keepdir is an implementation detail; that's my whole point here. I
don't need the directory (although it would be nice) and I really don't
need the keepdir file. But the GLEP eclass calls keepdir and the QA
warning flags it.
I'm leaning towards deleting the keepdir file and the directory from $D
to avoid the warning. We can tell people to create the home directory
themselves on the wiki. I don't want to selectively ignore the warning;
if it's generating false positives (I think it is), then the warning
should be fixed.
I like your /var/lib/amavis/{home,work} suggestion second-best, but the
most appropriate place for the home directory of an account that will be
used interactively by a human (even if it's also used to start a daemon)
is under /home. For example I do want to back up that home directory,
but I don't want to back up the working directory.
> That bug appears to be restricted. Perhaps it is embargoed? If not,
> then it probably shouldn't be restricted, especially if already fixed
> and GLSA'ed (and if it wasn't GLSA'ed then it isn't fixed, not that
> this has anything to do with you most likely).
It's embargoed because security-audit@ goes to /dev/null, but the bug is
already fixed. (If anyone can un-embargo my other 50 ancient security
bugs, just let me know who to bribe.)
> Portage should provide a safe mechanism to fix permissions. Or we
> should just avoid nesting user home directories inside directories
> that will be written to by that user.
>
> If this is the same hard-linking concern as with tmpfiles.d then
> somebody really just needs to fix POSIX. :) But as a workaround just
> avoiding nesting seems like the simpler solution...
Essentially yes, but hard links aren't the only problem. It's unsafe to
do anything as root in a user-controlled directory. POSIX can't fix
that, and that means that portage will never be able to fix permissions
(or do anything else) within a user-controlled directory safely.
Re: [gentoo-dev] New QA Policy Guide
On Sun, Jan 19, 2020 at 6:46 AM Ulrich Mueller wrote: > > > On Sun, 19 Jan 2020, Michał Górny wrote: > > > The sources are stored in proj/policy-guide.git [3]. If you wish to > > submit your own changes, you can either use the 'Policy Guide' bugzilla > > component [4] and/or GitHub mirror [5]. > > Please, no github for official policies. We should have a permanent > paper trail for this kind of things, which isn't guaranteed if the > discussion would happen entirely on github. > > Besides, by the Social Contract we cannot rely on a non-free service > for anything official. The official sources aren't in github. A bugzilla component is available, so if github goes away there is no problem and we aren't relying on it. It looks like there is the optional ability to do work on github, just as people can optionally talk about anything, anywhere. If I have a chat with another package maintainer at a bar, and they modify their ebuild and push that to the Gentoo repo on infra, and no bug is ever opened, that is 100% within our current policy. I don't see how having that discussion on github instead of at the bar changes things. They're just offering an alternative place to get things done. Anybody who wants to could just file a bug instead. If we want to have an additional Gentoo policy that nobody is allowed to discuss a Gentoo policy outside of the lists and bugzilla that would of course create issues with stuff like github, and probably non-logged IRC channels and private messages as well. However, that is not our current policy. Plenty of council decisions happen with much of the actual discussion not being recorded anywhere. I'm not sure you could reasonably operate in any other way, as people do need the ability to talk things out without having to posture. I feel like this discussion has already happened in the past though... -- Rich
Re: [gentoo-dev] New QA Policy Guide
> On Sun, 19 Jan 2020, Michał Górny wrote: > The sources are stored in proj/policy-guide.git [3]. If you wish to > submit your own changes, you can either use the 'Policy Guide' bugzilla > component [4] and/or GitHub mirror [5]. Please, no github for official policies. We should have a permanent paper trail for this kind of things, which isn't guaranteed if the discussion would happen entirely on github. Besides, by the Social Contract we cannot rely on a non-free service for anything official. Ulrich signature.asc Description: PGP signature
[gentoo-dev] New QA Policy Guide
Hello, In the light of the recent misunderstandings, I have started working on an official Policy Guide [1]. The Guide is meant to provide a focused list of officially approved QA policies, along with their rationale and any other useful information. This should supplement devmanual [2] with clear information on what is enforceable policy, and what is merely a suggestion (or possibly outdated information, which is a common problem for devmanual). The current document contents were approved by the QA project. However, it is by no means complete. Further existing policies (as well as new policies) will be documented there as they are approved by QA team. The sources are stored in proj/policy-guide.git [3]. If you wish to submit your own changes, you can either use the 'Policy Guide' bugzilla component [4] and/or GitHub mirror [5]. Enjoy! [1] https://projects.gentoo.org/qa/policy-guide/ [2] https://devmanual.gentoo.org/ [3] https://gitweb.gentoo.org/proj/policy-guide.git/ [4] https://bugs.gentoo.org/enter_bug.cgi?product=Documentation&component=Policy+Guide [5] https://github.com/gentoo/policy-guide -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP81 and /home
On Sat, Jan 18, 2020 at 9:50 PM Michael Orlitzky wrote: > > On 1/18/20 7:21 PM, Rich Freeman wrote: > > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote: > >> > >> But now users have to follow one more step (create /home/amavis) when > >> setting up amavisd-new. Is the QA check really assuring a quality user > >> experience here? > >> > > > > Lots of daemons need a home directory for their users, and usually > > they manage to get by in /var/lib. It really seems like a bad > > practice to start having packages creating stuff in /home. Certainly > > I don't want random daemons sticking stuff in /home, which I manage > > > > * The daemon DOES NOT need a home directory for its user. > * I DO NOT want to install anything to anyone's home directory. My concern isn't with installing stuff to "anyone's home directory." My concern is with creating ANYTHING in /home. Daemons are local users. There is no guarantee that /home is a local filesystem. Heck, there is no guarantee that /home is even mounted when portage is running. Portage shouldn't be touching /home at all. With stuff like automounted or encrypted home directories and systemd-homed and so on it seems like it is even more important to avoid sticking stuff in /home (and this is hardly something started by systemd - stuff in /home that is non-static has been a thing for some time - certainly it was happening in the 90s on some IRIX workstations I used). > * With respect to user.eclass, I'm proposing that /home be treated > EXACTLY THE SAME as it always has been. I'm not aware that it was ever considered good practice to stick stuff in /home. I suspect it just wasn't on QA's radar in the past. > > All I want to do is *set* a user's home directory to /home/foo. You don't just want to "set" it. You want to create the directory, which is modifying the filesystem (otherwise, why have a .keepdir?). And setting a home directory to something that doesn't exist doesn't seem like an improvement unless it is /dev/null. I get though that the daemon itself doesn't use the home directory, and that you just want it for configuring other stuff it might launch. > Spamassassin itself is a better example than amavis. We already set the > spamd user's home directory to /home/spamd with user.eclass. We don't > install anything there, and this works fine. If a human logs into that > account and generates some configuration in ~/.spamassassin, then it's > within the spirit of the FHS to have that data stored in /home. Looks like we might have another package to deal with, and perhaps others as well, depending on what comes out of this thread. > Now, with GLEP 81, we get a QA warning for that, because the eclass > installs a keepdir file there. I would like things to remain exactly as > they are, with no QA warning. Otherwise, we have to tell users to move > /home/spamd to /var/lib/spamd-home or something stupid like that. I can > think of no good reason to do so. Well, you won't get QA warnings from the tinderbox if the default home isn't under /home. Users who already have the home there might get warnings at install time. They can just ignore them. You could output an einfo to explain the situation to the user. If they're fine with /home then they can ignore the warning, and if they want to move it they can do so. I'll also note that GLEP 81 itself is silent on WHERE home directories should be placed. If some sort of definitive answer comes out of this thread the GLEP should probably be updated to reflect this, unless there is a better place to put it. Seems like the fact that this practice was undocumented in the past is part of how we got to where we're at. > > It seems like the straightforward solution is to stick everything in > > /var/lib/amavis, and fix things so that everything has the right > > permissions regardless of install order. > > Please stop telling people to do this. Calling chown on the live > filesystem is rarely safe, and I already fixed one root exploit (bug > 630836) in the amavisd-new ebuild from the last guy who tried to adjust > wrong permissions after the fact. That bug appears to be restricted. Perhaps it is embargoed? If not, then it probably shouldn't be restricted, especially if already fixed and GLSA'ed (and if it wasn't GLSA'ed then it isn't fixed, not that this has anything to do with you most likely). Portage should provide a safe mechanism to fix permissions. Or we should just avoid nesting user home directories inside directories that will be written to by that user. If this is the same hard-linking concern as with tmpfiles.d then somebody really just needs to fix POSIX. :) But as a workaround just avoiding nesting seems like the simpler solution... Just on a side note, I'm just stating an opinion here. I'm not in QA. Nobody should be construing my posts as "telling people" to do anything. And I do realize that you're just inheriting a situation that goes back probably quite a long time
