Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kubernetes-helmPlugins: build rather than download #3

Merged
merged 1 commit into from
Feb 25, 2021

Conversation

yurrriq
Copy link

@yurrriq yurrriq commented Feb 22, 2021

Motivation for this change

Build rather than download Helm plugins, which has the added (and desired) side effect of supporting Darwin.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@teto teto merged commit d87a39d into teto:helm-plugins Feb 25, 2021
teto pushed a commit that referenced this pull request Oct 17, 2021
teto pushed a commit that referenced this pull request Oct 17, 2021
teto pushed a commit that referenced this pull request Oct 17, 2021
teto pushed a commit that referenced this pull request Oct 17, 2021
teto pushed a commit that referenced this pull request Oct 17, 2021
…pt-fix3

update script fix #3 for fluxcd, k3s, linode-cli, linkerd
teto pushed a commit that referenced this pull request Feb 8, 2022
The test failed with

> Test "test5 user should not be able to run commands under root" failed with
> error: "invalid literal for int() with base 10: ''"

since 2492da8.

The reason for this is that `sudo(8)` writes the lecture to the
tty[1] and only as a fallback to stdout[2]. This means that the
`base64 --wrap 0` executed by `machine.execute()` doesn't affect the
text written to the terminal, however the lecture is part of the string
that's read from the VM via `shell.recv()`.

I confirmed the problem in an interactive test session[3]:

    >>> command = "sudo -u test5 sudo -n -u root true"
    >>> out_command = f"( set -euo pipefail; {command} ) | (base64 --wrap 0; echo)\n"
    >>> machine.shell.send(out_command.encode())
    84

    >>> machine # [   99.015512] sudo[877]:     root : TTY=hvc0 ; PWD=/tmp ; USER=test5 ; COMMAND=/run/wrappers/bin/sudo -n -u root true
    machine # [   99.019373] sudo[877]: pam_unix(sudo:session): session opened for user test5(uid=1005) by (uid=0)
    machine # [   99.038692] sudo[879]: pam_unix(sudo:auth): conversation failed
    machine # sudo: a password is required
    machine # [   99.041860] sudo[879]: pam_unix(sudo:auth): auth could not identify password for [test5]
    machine # [   99.046901] sudo[877]: pam_unix(sudo:session): session closed for user test5
    >>>
    >>> x=machine._next_newline_closed_block_from_shell()
    >>> print(x)
    <newline>
    We trust you have received the usual lecture from the local System
    Administrator. It usually boils down to these three things:
    <newline>
        #1) Respect the privacy of others.
        #2) Think before you type.
        #3) With great power comes great responsibility.
    <newline>
    <newline>
    <newline>
    >>>

Since the lecture isn't strictly necessary to confirm that
`security.sudo` works as expected, I decided to disable lecturing
inside the test, however we may want to fix the underlying problem in
the test-driver at some point.

[1] https://github.com/sudo-project/sudo/blob/SUDO_1_9_9/plugins/sudoers/check.c#L275-L283
[2] https://github.com/sudo-project/sudo/blob/SUDO_1_9_9/src/conversation.c#L95-L120
[3] I replaced each empty line with `<newline>` to make sure these
    aren't swallowed by git.
teto pushed a commit that referenced this pull request Oct 12, 2022
systemd: Fix systemd-{cryptenroll,cryptsetup} TPM2 and FIDO2 support (attempt #3)
teto pushed a commit that referenced this pull request Jan 5, 2023
Without this change it segfaults when trying to play any media:

  $ jellyfinmediaplayer
  Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
  libpng warning: iCCP: known incorrect sRGB profile
  Logging to /home/bf/.local/share/jellyfinmediaplayer/logs/jellyfinmediaplayer.log
  Cannot load libcuda.so.1
  Segmentation fault (core dumped)

The backtrace shows pipewire being at fault:

  $ coredumpctl debug
  [...]
  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  0x00007f711428c9bb in core_event_demarshal_remove_id () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
  [Current thread is 1 (Thread 0x7f6ffdc87640 (LWP 1360949))]
  (gdb) bt
  #0  0x00007f711428c9bb in core_event_demarshal_remove_id () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
  #1  0x00007f711428886c in process_remote () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
  #2  0x00007f7114288e68 in on_remote_data () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
  #3  0x00007f7114310efe in loop_iterate () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/spa-0.2/support/libspa-support.so
  #4  0x00007f71266fe7f2 in do_loop () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/libpipewire-0.3.so.0
  NixOS#5  0x00007f7128b08e86 in start_thread () from /nix/store/ayfr5l52xkqqjn3n4h9jfacgnchz1z7s-glibc-2.35-224/lib/libc.so.6
  NixOS#6  0x00007f7128b8fce0 in clone3 () from /nix/store/ayfr5l52xkqqjn3n4h9jfacgnchz1z7s-glibc-2.35-224/lib/libc.so.6
  (gdb)

Standalone mpv doesn't segfault (when directly playing the underlying
media files). I don't know why.

Fixes: b97cda7 ("mpv-unwrapped: 0.34.1 -> 0.35.0")

Fixes NixOS#205141

Ref jellyfin/jellyfin-media-player#341
teto pushed a commit that referenced this pull request Oct 26, 2023
teto pushed a commit that referenced this pull request Feb 21, 2024
Since ba83271 the build fails with

    applying patch /nix/store/46rxbbvl2l3mrxb50y9rzy7ahgx0lraj-d741901dddd731895346636c0d3556c6fa51fbe6.patch
    patching file tests/hazmat/primitives/test_aead.py
    Hunk #1 FAILED at 56.
    Hunk #2 FAILED at 197.
    Hunk #3 FAILED at 378.
    Hunk #4 FAILED at 525.
    Hunk NixOS#5 FAILED at 700.
    Hunk NixOS#6 FAILED at 844.
    6 out of 6 hunks FAILED -- saving rejects to file tests/hazmat/primitives/test_aead.py.rej
teto pushed a commit that referenced this pull request Mar 1, 2024
Without the change `unnethack` startup crashes as:

    (gdb) bt
    #0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
    #1  0x00007f734250c0e3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
    #2  0x00007f73424bce06 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
    #3  0x00007f73424a58f5 in __GI_abort () at abort.c:79
    #4  0x00007f73424a67a1 in __libc_message (fmt=fmt@entry=0x7f734261e2f8 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:150
    NixOS#5  0x00007f734259b1d9 in __GI___fortify_fail (msg=msg@entry=0x7f734261e2df "buffer overflow detected") at fortify_fail.c:24
    NixOS#6  0x00007f734259ab94 in __GI___chk_fail () at chk_fail.c:28
    NixOS#7  0x00000000005b2ac5 in strcpy (__src=0x7ffe68838b00 "Shall I pick a character's race, role, gender and alignment for you? [YNTQ] (y)",
        __dest=0x7ffe68838990 "\001") at /nix/store/B0S2LKF593R3585038WS4JD3LYLF2WDX-glibc-2.38-44-dev/include/bits/string_fortified.h:79
    NixOS#8  curses_break_str (str=str@entry=0x7ffe68838b00 "Shall I pick a character's race, role, gender and alignment for you? [YNTQ] (y)", width=width@entry=163,
        line_num=line_num@entry=1) at ../win/curses/cursmisc.c:275
    NixOS#9  0x00000000005b3f51 in curses_character_input_dialog (prompt=prompt@entry=0x7ffe68838cf0 "Shall I pick a character's race, role, gender and alignment for you?",
        choices=choices@entry=0x7ffe68838d70 "YNTQ", def=def@entry=121) at ../win/curses/cursdial.c:211
    NixOS#10 0x00000000005b9ca0 in curses_choose_character () at ../win/curses/cursinit.c:556
    NixOS#11 0x0000000000404eb1 in main (argc=<optimized out>, argv=<optimized out>) at ./../sys/unix/unixmain.c:309

which corresponds to `gcc` warning:

    ../win/curses/cursmisc.c: In function 'curses_break_str':
    ../win/curses/cursmisc.c:275:5: warning: '__builtin___strcpy_chk' writing one too many bytes into a region of a size that depends on 'strlen' [-Wstringop-overflow=]
      275 |     strcpy(substr, str);
          |     ^

I did not find a single small upstream change that fixes it. Let's
disable `fortify3` until next release.

Closes: NixOS#292113
teto pushed a commit that referenced this pull request Aug 27, 2024
Strongly inspired by the forgejo counterpart[1], for the following
reasons:

* The feature is broken with the current module and crashes on
  authentication with the following stacktrace (with a PAM service
  `gitea` added):

      server # Stack trace of thread 1008:
      server # #0  0x00007f3116917dfb __nptl_setxid (libc.so.6 + 0x8ddfb)
      server # #1  0x00007f3116980ae6 setuid (libc.so.6 + 0xf6ae6)
      server # #2  0x00007f30cc80f420 _unix_run_helper_binary (pam_unix.so + 0x5420)
      server # #3  0x00007f30cc8108c9 _unix_verify_password (pam_unix.so + 0x68c9)
      server # #4  0x00007f30cc80e1b5 pam_sm_authenticate (pam_unix.so + 0x41b5)
      server # NixOS#5  0x00007f3116a84e5b _pam_dispatch (libpam.so.0 + 0x3e5b)
      server # NixOS#6  0x00007f3116a846a3 pam_authenticate (libpam.so.0 + 0x36a3)
      server # NixOS#7  0x00000000029b1e7a n/a (.gitea-wrapped + 0x25b1e7a)
      server # NixOS#8  0x000000000047c7e4 n/a (.gitea-wrapped + 0x7c7e4)
      server # ELF object binary architecture: AMD x86-64
      server #
      server # [   42.420827] gitea[897]: pam_unix(gitea:auth): unix_chkpwd abnormal exit: 159
      server # [   42.423142] gitea[897]: pam_unix(gitea:auth): authentication failure; logname= uid=998 euid=998 tty= ruser= rhost=  user=snenskek

  It only worked after turning off multiple sandbox settings and adding
  `shadow` as supplementary group to `gitea.service`.

  I'm not willing to maintain additional multiple sandbox settings for
  different features, especially given that it was probably not used for
  quite a long time:

  * There was no PR or bugreport about sandboxing issues related to
    PAM.

  * Ever since the module exists, it used the user `gitea`, i.e. it had
    never read-access to `/etc/shadow`.

* Upstream has it disabled by default[2].

If somebody really needs it, it can still be brought back by an overlay
updating `tags` accordingly and modifying the systemd service config.

[1] 07641a9
[2] https://docs.gitea.com/usage/authentication#pam-pluggable-authentication-module
teto pushed a commit that referenced this pull request Jan 9, 2025
nixosTests.cryptpad started failing recently.

Investigating the issue shows that seccomp has become problematic during
the init phase, (e.g. this can be reproduced by removing the customize
directory in /var/lib/cryptpad):

machine # [   10.774365] systemd-coredump[864]: Process 756 (node) of user 65513 dumped core.
machine #
machine # Module libgcc_s.so.1 without build-id.
machine # Module libstdc++.so.6 without build-id.
machine # Module libicudata.so.74 without build-id.
machine # Module libicuuc.so.74 without build-id.
machine # Module libicui18n.so.74 without build-id.
machine # Module libz.so.1 without build-id.
machine # Module node without build-id.
machine # Stack trace of thread 756:
machine # #0  0x00007ff951974dcb fchown (libc.so.6 + 0x107dcb)
machine # #1  0x00007ff95490d0c0 uv__fs_copyfile (libuv.so.1 + 0x150c0)
machine # #2  0x00007ff95490d89a uv__fs_work (libuv.so.1 + 0x1589a)
machine # #3  0x00007ff954910c76 uv_fs_copyfile (libuv.so.1 + 0x18c76)
machine # #4  0x0000000000eb8a39 _ZN4node2fsL8CopyFileERKN2v820FunctionCallbackInfoINS1_5ValueEEE (node + 0xab8a39)
machine # NixOS#5  0x0000000001cda5e2 Builtins_CallApiCallbackGeneric (node + 0x18da5e2)
[...]
machine # [   10.877468] cryptpad[685]: /nix/store/h4yhhxpfm03c5rgz91q7jrvknh596ly2-cryptpad-2024.12.0/bin/cryptpad: line 3:   756 Bad system call         (core dumped) "/nix/store/fkyp1bm5gll9adnfcj92snyym524mdrj-nodejs-22.11.0/bin/node" "/nix/store/h4yhhxpfm03c5rgz91q7jrvknh596ly2-cryptpad-2024.12.0/lib/node_modules/cryptpad/scripts/build.js"

nodejs 20.18 rightly did not require chown when the source and
destination are the same owner (heck, the script does not run as
root so even if it is not blocked there is no way it'd work with a
different owner...)

For now just allow chown calls again, this is not worth wasting more
time.

Fixes NixOS#370717
teto pushed a commit that referenced this pull request Feb 19, 2025
This test crashes the python interpreter in libx265_encode_stream:

```
 #0  0x00007feefe2a7a7e in free () from /nix/store/81mi7m3k3wsiz9rrrg636sx21psj20hc-glibc-2.40-66/lib/libc.so.6
 No symbol table info available.
 #1  0x00007fee98059295 in av_free (ptr=<optimized out>) at libavutil/mem.c:243
 No locals.
 #2  0x00007fee98059352 in av_freep (arg=<optimized out>) at libavutil/mem.c:253
        val = <optimized out>
 #3  0x00007fee997a4713 in libx265_encode_frame (avctx=<optimized out>, pkt=<optimized out>, pic=<optimized out>,
    got_packet=0x7ffe35c7e3f4) at libavcodec/libx265.c:821
    [...]
 #4  0x00007fee99526ff6 in ff_encode_encode_cb (avctx=avctx@entry=0x16d1f00, avpkt=avpkt@entry=0x16ad440, frame=0x16f5e80, got_packet=got_packet@entry=0x7ffe35c7e3f4) at libavcodec/encode.c:254
        codec = 0x7fee9a25e5c0 <ff_libx265_encoder>
 [...]
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants