PermissionDenied in library/std/src/sys/pal/unix/time.rs:131:68 while building a package

[hades]

Bug Description

I have a very interesting issue, which is probably not super important to resolve, but maybe someone's interest is piqued and they'd like to dig deeper.

The short description is: I'm trying to build a package (cryptography) using pip under Docker running on a Raspberry Pi, which fails with the following error:

      ===================================================================
      maturin has panicked. This is a bug in maturin. Please report this
      at https://github.com/PyO3/maturin/issues/new/choose.
      If you can reliably reproduce this panic, include the
      reproduction steps and re-run with the RUST_BACKTRACE=1 environment
      variable set and include the backtrace in your report.
      
      Platform: linux arm
      Version: 1.9.2
      Args: maturin pep517 build-wheel -i /test_env/bin/python3 --compatibility off
      
      
      thread 'main' panicked at library/std/src/sys/pal/unix/time.rs:131:68:
      called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }
      stack backtrace:
         0: __rustc::rust_begin_unwind
         1: core::panicking::panic_fmt
         2: core::result::unwrap_failed
         3: std::sys::pal::unix::time::Timespec::now
         4: zip::types::DateTime::default_for_write
         5: maturin::module_writer::ModuleWriter::add_bytes
         6: maturin::module_writer::WheelWriter::new
         7: maturin::build_context::BuildContext::build_pyo3_wheel_abi3
         8: maturin::build_context::BuildContext::build_wheels
         9: maturin::run
        10: maturin::main
      note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
      Error: command ['maturin', 'pep517', 'build-wheel', '-i', '/test_env/bin/python3', '--compatibility', 'off'] returned non-zero exit status 101
      [end of output]

The cause of the error is a call to clock_gettime64:

1010  clock_gettime64(CLOCK_REALTIME, 0x7eade490) = -1 EPERM (Operation not permitted)

I'm not exactly sure how 64-bit syscalls are supposed to work on 32-bit ARM systems, and why this would cause an EPERM. I started digging into it, and I'll update this issue if I find any answers, but in the meantime I just moved this entire project away from Raspberry Pi.

Additional info:

$ uname -a
Linux kerberos 5.10.103-v7+ #1529 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l GNU/Linux
$ sudo docker -v
Docker version 26.1.4, build 5650f9b

Your maturin version (maturin --version)

1.9.2

Your Python version (python -V)

3.12.11

Your pip version (pip -V)

25.0.1

What bindings you're using

None

Does cargo build work?

• Yes, it works

If on windows, have you checked that you aren't accidentally using unix path (those with the forward slash /)?

• Yes

Steps to Reproduce

1. Build the following Docker image:

FROM alpine:3.22

ENV RUST_BACKTRACE=1

RUN apk add python3 py3-pip gcc cargo rust python3-dev libffi-dev openssl-dev
RUN python3 -m venv /test_env
RUN /test_env/bin/python -V
RUN /test_env/bin/pip -V
RUN /test_env/bin/pip install cryptography

[hades]

After some investigation it looks like the root cause is in Docker. It seems it sets up seccomp to return EPERM for clock_gettime64. The (possible) solution is to disable seccomp by running docker with --privileged.

Of course, arguably, getting EPERM should not have panicked the userspace binary. It is worth considering whether the time library in Rust should handle errors from clock_gettime. I'll leave this issue open.

Corresponding Rust issue: rust-lang/rust#115482