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

A small fix to fetchgit for git 2.18.0 update #1

Merged
merged 1 commit into from
Jun 25, 2018

Conversation

layus
Copy link

@layus layus commented Jun 25, 2018

No description provided.

@layus layus mentioned this pull request Jun 25, 2018
9 tasks
@dtzWill dtzWill merged this pull request into dtzWill:update/git-2.18.0 Jun 25, 2018
@layus layus deleted the fix-fetchgit branch June 25, 2018 16:03
dtzWill pushed a commit that referenced this pull request Jul 9, 2018
This adds some initial values for .dir-locals.el. Mainly this is
useful for using bug-reference-mode.

So if you have bug-reference-mode enabled -

> M-x bug-reference-mode

You will see as clickable text like this:

  Fixes NixOS#15

  (NixOS#12)

  Closed NixOS#1252

  issue #1
dtzWill pushed a commit that referenced this pull request Aug 26, 2018
worldofpeace pushed a commit that referenced this pull request Dec 12, 2018
…g with it

Change introduced in NixOS#50672.

The patch does not apply on older protobuf like protobuf3_1

```
$ nix-build -E 'with import ./. { }; python3Packages.protobuf.override { protobuf = protobuf3_1; }'
unpacking sources
unpacking source archive /nix/store/1zdyl0cxaa8ha2v1zp75zzdjd6j99d0m-source
source root is source
setting SOURCE_DATE_EPOCH to timestamp 315619200 of file source/util/python/BUILD
patching sources
applying patch /nix/store/yagx7hvylnnjq7lxbcia0y5lq1r736w3-0a59054c30e4f0ba10f10acfc1d7f3814c63e1a7.patch
patching file google/protobuf/pyext/descriptor.cc
Hunk #1 succeeded at 55 (offset -1 lines).
patching file google/protobuf/pyext/descriptor_containers.cc
patching file google/protobuf/pyext/descriptor_pool.cc
Hunk #1 succeeded at 47 (offset -1 lines).
patching file google/protobuf/pyext/extension_dict.cc
Hunk #1 FAILED at 53.
1 out of 1 hunk FAILED -- saving rejects to file google/protobuf/pyext/extension_dict.cc.rej
patching file google/protobuf/pyext/message.cc
Hunk #1 succeeded at 82 (offset 3 lines).
Hunk #2 succeeded at 1425 (offset -104 lines).
```

Since the patch isn't necessary on python versions older than 3.7, let's
only apply it for version 3.7. This means that most things using older
protobuf implementation will now be able to build when using an older
pythonPackage set (as is most probably the case anyway).

This still leaves protobuf 3.1 using packages hanging, but the errors
will be localized to those that would be breaking anyway with the
upgrade to 3.7 as default python.
dtzWill pushed a commit that referenced this pull request Mar 7, 2019
The sed expression actually caused an error on hydra:
```
sed: -e expression #1, char 18: Invalid collation character
```
It seems to build fine without it however.
dtzWill pushed a commit that referenced this pull request Jul 18, 2019
dtzWill added a commit that referenced this pull request Jul 25, 2019
Jul 25 14:49:58 dtznix systemd[1825]: Started Compton X11 compositor.
Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.615 glx_has_extension ERROR ] Failed get GLX extension list.
Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.615 glx_has_extension ERROR ] Failed get GLX extension list.
Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.616 glx_has_extension ERROR ] Failed get GLX extension list.
Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.616 glx_has_extension ERROR ] Failed get GLX extension list.
Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.616 glx_has_extension ERROR ] Failed get GLX extension list.
Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.616 glx_init ERROR ] Root visual is not a GL visual.
Jul 25 14:49:58 dtznix compton[20087]: [ 07/25/2019 14:49:58.616 initialize_backend FATAL ERROR ] Failed to initialize backend, abort>
Jul 25 14:49:58 dtznix compton[20087]: =================================================================
Jul 25 14:49:58 dtznix compton[20087]: ==20087==ERROR: LeakSanitizer: detected memory leaks
Jul 25 14:49:58 dtznix compton[20087]: Direct leak of 716 byte(s) in 16 object(s) allocated from:
Jul 25 14:49:58 dtznix compton[20087]:     #0 0x4f5f67  (/nix/store/zdk6cxvwjjni77g14ma6m1g1n29kms7a-compton-7/bin/compton+0x4f5f67)
Jul 25 14:49:58 dtznix compton[20087]:     #1 0x7ff287d3b27b  (/nix/store/6c7qpk39yihg41ssdbzgd7g7nzfm3ic5-libxcb-1.13.1/lib/libxcb.s>
Jul 25 14:49:58 dtznix compton[20087]: SUMMARY: AddressSanitizer: 716 byte(s) leaked in 16 allocation(s).
Jul 25 14:49:58 dtznix systemd[1825]: compton.service: Main process exited, code=exited, status=1/FAILURE
dtzWill pushed a commit that referenced this pull request Dec 5, 2019
dtzWill pushed a commit that referenced this pull request Dec 5, 2019
roundcube: tests - add space to db password, check setup script worked
dtzWill pushed a commit that referenced this pull request Jan 6, 2020
dtzWill 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.
dtzWill pushed a commit that referenced this pull request Apr 6, 2022
This effectively fixes the majority of all VM tests which were broken
because `/dev/vda` (or any other block device) wasn't mountable:

      machine # mounting /dev/vda on /...
      machine # mount: mounting /dev/vda on /mnt-root/ failed: No such device[    2.820976] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
      machine # [    2.821757] CPU: 0 PID: 1 Comm: init Not tainted 5.10.72 #1-NixOS
      machine # [    2.821757] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
      machine # [    2.821757] Call Trace:
      machine # [    2.821757]  dump_stack+0x6b/0x83
      machine # [    2.821757]  panic+0x101/0x2c8
      machine # [    2.821757]  do_exit.cold+0x14/0xb3
      machine # [    2.821757]  do_group_exit+0x33/0xa0
      machine # [    2.821757]  __x64_sys_exit_group+0x14/0x20
      machine # [    2.821757]  do_syscall_64+0x33/0x40
      machine # [    2.821757]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      machine # [    2.821757] RIP: 0033:0x7f67ec2800f6
      machine # [    2.821757] Code: 00 4c 8b 0d 2c 5d 11 00 eb 19 66 2e 0f 1f 84 00 00 00 00 00 89 d7 89 f0 0f 05 48 3d 00 f0 ff ff 77 22 f4 89 d7 44 89 c0 0f 05 <48> 3d 00 f0 ff ff 76 e2 f7 d8 64 41 89 01 eb da 66 2e 0f 1f 84 00
      machine # [    2.821757] RSP: 002b:00007fff8f5a71d8 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7
      machine # [    2.821757] RAX: ffffffffffffffda RBX: 0000000000699704 RCX: 00007f67ec2800f6
      machine # [    2.821757] RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
      machine # [    2.821757] RBP: 0000000000000004 R08: 00000000000000e7 R09: ffffffffffffff80
      machine # [    2.821757] R10: 00007f67ec33f3e0 R11: 0000000000000202 R12: 000000000000000b
      machine # [    2.821757] R13: 00007fff8f5a75a8 R14: 0000000000000000 R15: 00000000004fc198
      machine # [    2.821757] Kernel Offset: 0x31e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
      machine # [    2.821757] Rebooting in 1 seconds..

This happened because the kernel failed to load modules such as `ext4`
from `boot.initrd.availableKernelModules`[1] on e.g. a `mount(2)` syscall.

The problem is that `kmod` isn't linked against `libpthread.so.0`
anymore because it got merged into `libc.so.6` (however, the .so still
exists), but still needs it:

      machine # newfstatat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib/x86_64", 0x7ffd951114c0, 0) = -1 ENOENT (No such file or directory)
      machine # openat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
      machine # newfstatat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib/x86_64", 0x7ffd951114c0, 0) = -1 ENOENT (No such file or directory)
      machine # openat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
      machine # newfstatat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/lib", 0x7ffd951114c0, 0) = -1 ENOENT (No such file or directory)
      machine # openat(AT_FDCWD, "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.34-36/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
      machine # writev(2, [{iov_base="/nix/store/kdc9n48ksdc1a8y8w512w"..., iov_len=69}, {iov_base=": ", iov_len=2}, {iov_base="error while loading shared libra"..., iov_len=36}, {iov_base=": ", iov_len=2}, {iov_base="libpthread.so.0", iov_len=15}, {iov_base=": ", iov_len=2}, {iov_base="cy
      machine # ) = 184
      machine # exit_group(127)                         = ?
      machine # +++ exited with 127 +++
      machine # mount: mounting /dev/vda on /mnt-root/ failed: No such device
      machine # [   19.167180] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
      machine # [   19.167711] CPU: 0 PID: 1 Comm: init Not tainted 5.10.72 #1-NixOS

This is not a problem

* inside stage-1 because `LD_LIBRARY_PATH` points to `$out/lib` of
  extra-utils where `libpthread.so.6` also exists.
* on a running system because `${pkgs.glibc}/lib` is part of kmod's
  rpath.

However this is a problem inside the kernel which calls `modprobe` (in
our case `kmod`) to load modules and doesn't know about
`LD_LIBRARY_PATH`. Also, the rpath-reference was nuked.

To work around this, the kernel's `modprobe`
(i.e. `/proc/sys/kernel/modprobe`) now points to a wrapper which
explicitly declares `LD_LIBRARY_PATH`. We can't use `makeWrapper` here
because `modprobe` itself must not be renamed. Otherwise, `kmod` (which
is the link-target of `modprobe`) won't work because it expects
`argv[0] == "modprobe"` to perform modprobe's tasks.

[1] https://nixos.org/manual/nixos/stable/options.html#opt-boot.initrd.availableKernelModules
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