Nixpkgs: p11-kit fails to build locally on non-NixOS systems (single-user install) due to failing tests on master

[mjlbach]

Describe the bug
p11-kit builds on nixos/hydra, but fails on non-nixos systems in single-user installs (not multi-user) due to failing test.

Similar issue: https://github.com/NixOS/nixpkgs/issues/72838

test-conf: common/test.c:612: p11_test_copy_setgid: Assertion `false && "this code should not be reached"' failed.
./build/litter/tap-driver.sh: line 639: 56517 Aborted                 (core dumped) "$@"
ERROR: test-conf - missing test plan

============================================================================
Testsuite summary for p11-kit 0.23.21
============================================================================
# TOTAL: 743
# PASS:  741
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 2
============================================================================
See ./test-suite.log
Please report to https://github.com/p11-glue/p11-kit/issues
============================================================================
make[4]: *** [Makefile:4928: test-suite.log] Error 1
make[4]: Leaving directory '/build/source'
make[3]: *** [Makefile:5036: check-TESTS] Error 2
make[3]: Leaving directory '/build/source'
make[2]: *** [Makefile:5640: check-am] Error 2
make[2]: Leaving directory '/build/source'
make[1]: *** [Makefile:4813: check-recursive] Error 1
make[1]: Leaving directory '/build/source'
make: *** [Makefile:5643: check] Error 2
builder for '/nix/store/r6mh4dp2vqlhfr5j7x6wpdy9snp6bl08-p11-kit-0.23.21.drv' failed with exit code 2
error: build of '/nix/store/r6mh4dp2vqlhfr5j7x6wpdy9snp6bl08-p11-kit-0.23.21.drv' failed

To Reproduce
Steps to reproduce the behavior:

1. nix-shell -I nixpkgs=https://github.com/nixos/nixpkgs/archive/master.tar.gz -p p11-kit --check

Expected behavior
p11-kit succeeded on hydra, so I assumed it would succeed locally

Additional context
I ran into this issue trying to review https://github.com/NixOS/nixpkgs/pull/94637

Notify maintainers
None, recent/involved: @worldofpeace @FRidh

Metadata

❯ nix-shell -p nix-info --run "nix-info -m"
these paths will be fetched (0.00 MiB download, 0.00 MiB unpacked):
  /nix/store/iinpypz3m7d68kqcb043qi9iiwvsm6pm-nix-info
copying path '/nix/store/iinpypz3m7d68kqcb043qi9iiwvsm6pm-nix-info' from 'https://cache.nixos.org'...
 - system: `"x86_64-linux"`
 - host os: `Linux 5.7.16-200.fc32.x86_64, Fedora, 32 (Workstation Edition)`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.7`
 - channels(michael): `"nixos-unstable-20.09pre239318.c59ea8b8a0e, nixpkgs-20.09pre240426.f9567594d5a"`
 - nixpkgs: `/home/michael/.nix-defexpr/channels/nixpkgs`

[worldofpeace]

This is labeled as a channel blocker because p11-kit is in the gnome3 closure.
cc @nixos/gnome

[worldofpeace]

I couldn't reproduce this @mjlbach on NixOS 20.09

- system: `"x86_64-linux"`
 - host os: `Linux 5.4.59, NixOS, 20.09.20200810.dirty (Nightingale)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4pre20200721_ff314f1`
 - channels(root): `""`
 - nixpkgs: `/nix/store/blavjn6via2al4msbnc01vvhn36l8xiz-fm6qxbi0l03mykyzrafjinxkm4jxxnn9-source`

[mjlbach]

@worldofpeace Thanks for checking, I'm not sure what it could be about my local system then. I can try to debug/test on a couple vms.

edit: I've reproduced now on two non-nixos systems (fedora 32 and ubuntu 18.04)

[worldofpeace]

@mjlbach Yeah, from looking at https://hydra.nixos.org/job/nixpkgs/trunk/p11-kit.x86_64-linux it seems on nixos linux the build is successful. We actually happen to have the tests on darwin disabled (perhaps for a similar reason). I'm not sure there's a way to detect in stdenv non-nixos linux to disable the test as well. Though there could be an actual issue.

[mjlbach]

Updated the issue title and description to make it more clear this does not affect NixOS, but rather linux systems using nix.

[mjlbach]

One option would be to have an "allowlist" for tests. Something like (not sure if this is the right platform name)

doCheck = hostPlatform.system == "x86_64-nixos"

Although i'm curious why exactly it fails on non-nixos systems.

[andersk]

My hostPlatform.system on NixOS is

$ nix eval -f '<nixpkgs>' hostPlatform.system
"x86_64-linux"

which I assume is the same as non-NixOS.

[mjlbach]

My hostPlatform.system on NixOS is

$ nix eval -f '<nixpkgs>' hostPlatform.system
"x86_64-linux"

which I assume is the same as non-NixOS.

Yes, that's what I was hoping was not the case (my nixos machine is unfortunately inaccessible right now) . Maybe there should be a stdenv.isNixOS... Not sure how widespread these sorts of failures are.

[andersk]

Based on looking at the p11_test_copy_setgid code, perhaps this happens when you have /tmp on a filesystem mounted nosuid?

[mjlbach]

Yes, that seems to be the case:

$ mount
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,seclabel)

Although this seems to be standard for systemd managed systems? (ubuntu, fedora, etc.)

[andersk]

Actually, the callers of p11_test_copy_setgid pass in BUILDDIR rather than /tmp, so it might be some other filesystem that matters.

[andersk]

/run maybe? See nixos/nix#2957.

[mjlbach]

I'm not sure how to verify that, but based on the issue description I tried

 TMPDIR=/tmp nix-shell -I nixpkgs=https://github.com/nixos/nixpkgs/archive/master.tar.gz -p p11-kit --check

And still reproduced my issue

[vcunat]

This doesn't block a channel, right?

[vcunat]

BTW, I don't reproduce the issue on my sandboxed non-NixOS builder (Ubuntu 18.04 as well) or a NixOS one; both have nosuid /tmp.

_Current master, result /nix/store/j9199a0p4847pc1f1czjfrkw7nf6f0rn-p11-kit-0.23.21._

[worldofpeace]

This doesn't block a channel, right?

Yep, I forgot to unlabel it.

[mjlbach]

@vcunat Thanks for the info. Are you using a single or multi-user install? I have sandboxing (explicitly) enabled on both the ubuntu and fedora vms, but it's installed via single-user (not sure if this matters, but I have no idea what other substantive difference there could be).

[vcunat]

Yes, multi-user.

[mjlbach]

I've confirmed this issue only affects systems in single-user install.

[mjlbach]

One issue is that in order to use multi-user installs on redhat based linux distributions, it seems you have to disable SELinux