Move `fcntl_getfd`, `fcntl_setfd`, and `fcntl_dupfd_cloexec` out of
the `fs` module and into the `io` module, since they're not specific
to files, directories or memfd. This allows them to be used with the
"fs" feature is not enabled.
Also, add public aliases for then in `fs`, for compatibility, and to
have a place where all `fcntl` function are present.
And add a CI check for --no-default-features with no API features.
Fixes#453.
Fix a few minor clippy lints, and add clippy overrides for warnings that
we can't easily fix due to our MSRV, or due to our support of multiple targets.
Rustix no longer has anything in the tree that needs the `fs` module
when the public "fs" feature isn't enabled, so make the `fd` module
conditional on `cfg(feature = "fs")`.
As a followup to #444, remove the uid/gid checks from the procfs code
entirely. Procfs files can have their owner changed to root:root under
`PR_SET_DUMPABLE`, and root can be remapped to nobody by user
namespaces.
This check wasn't guarding against a known problem, and it's complex
to make sure it doesn't spuriously fail under any vald configuration,
so just remove it.
When a process is marked as non-dumpable, Linux changes the permissions
of the files under /proc/<pid> as owned by root:root. Relax the procfs
code, including removing use of `O_NOATIME`, so that it works on files
owned by `root:root`.
Fixes#441.
Update `src/net/ip.rs` and `src/net/addr.rs` to use the new std code,
making these structures platform independent.
Doesn't include the new Debug/Display formatting code for these
structures, although that could have been added now that it doesn't
depend on std anymore.
Do not resize internal buffer on error, otherwise iterator gets stuck in
infinite loop with zeroed `dirent`s after the first error. Correct
behavior is to return error indefinitely if it persists.
Error can be ENOENT if the directory is unlinked while iterating, for
example.
Signed-off-by: Aleksandr Trukhin <alxtry@gmail.com>
`#[cfg(target_feature = "thumb-mode")]` isn't available on stable, so
use a build.rs script to detect whether we can use `r7` in inline asm
on ARM targets.
* Fix linux-raw inline asm for thumb-mode.
In thumb-mode, r7 is reserved as the frame pointer and isn't permitted
as an inline asm operand. It's still the syscall-number operand in
syscalls though, so pass the syscall-number operand in in a separate
register, copy it into r7 inside the inline asm, and then restore the
value of r7 when we're done.
* Add a thumbv7neon-unknown-linux-gnueabihf line to CI.
* Fix compilation on sparc targets.
Adjust cfg's as needed to fix compilation errors on sparc.
Fixes#408.
* Rust's 32-bit sparc Linux target has a 32-bit time_t.
Add a tier-3 CI check for x86_64-unknown-dragonfly, and fix the
compilation errors needed to compile with --features=all-apis.
This builds on top of #409!
Remove rustix::io::OwnedFd, and just use the std and io_lifetimes'
OwnedFd definition. Now that rustix is using io_lifetimes 1.0, which has
switched to using the `OwnedFd` in std, this is no longer needed.
This simplifies rustix' API, as users no longer have to be aware of the
difference between rustix::io::OwnedFd and rustix::fd::OwnedFd.
The main change here is the removal of `FromFd` and `IntoFd` in favor of
`From<OwnedFd>` and `impl<T> or OwnedFd`.
This also adds impls for std types for rustix::io::OwnedFd to make it
less inconvenient to work with.
* Switch from `.init_array` constructors to /proc/self/auxv.
In the linux_raw backend, switch from using a `.init_array` constructor
for obtaining the aux values to reading them from /proc/self/auxv. This avoids
problems in situation where other Rust code can run before the constructor,
potentially distrupting the `__environ` value.
Also, for the linux_raw backend, introduce a new "use-libc-auxv" feature,
which enables use of libc to read the aux values, instead of reading
them from /proc/self/auxv.
The "use-libc-auxv" option is enabled by default, because it's more
efficient and doesn't depend on /proc, so it's likely better for most
users.
Mustang, for its part, continues to be able to use the incoming auxv on
the stack because it controls program startup. Since it doesn't have to
worry about the hazards of /proc or QEMU, it can trust the incoming
values, and do less checking.
Fixes#382.
* Remove the param `init` function from the libc backend.
* Fix the no-std build.
* Fix the backends test to accept that the default options now depend on libc.
* Use `NonNull` in `check_raw_pointer`'s return type.
This allows it to pack the return value into a single pointer-sized
value.
* Update more code to the new `check_raw_pointer` API.
* Fix an unused-import warning.
* Fix copy+paste.
* Thread `check_elf_base` through `check_vdso_base` too.
* Add a `Result` to `getpgid`, and add `getpgrp`.
Add a `Result` return type to `getpgid`, as it can fail if there's no
process with the given pid.
And, add a a `getpgrp` function, which is similar to `getpgid`, but
doesn't take a pid argument and always operates on the current process,
which means it doesn't need a `Result` return type.
* Use `getpgid` on platforms which don't have a `getpgrp` syscall.
The `madvise` was there to test whether the `AT_SYSINFO_EHDR` pointer
was a valid pointer before dereferencing it. However, in situation where
the `madvise` would fail, plain dereferences should reliably segfault,
which is sufficient for this code.
* Guard against future `statx` fields.
Future versions of Linux may recognize new `statx` mask flags, which
enable writing to new `struct statx` fields. If a rustix user constructs
a flags value with `from_bits_unchecked`, they could potentially create
a flags value that causes `statx` on such a future Linux version to write
fields outside the buffer, evoking undefined behavior.
This is very unlikely to be a practical problem today, because:
- Scanning all known public users of rustix, I don't see any constructing
`StatxFlags` values this way.
- It's unlikely that any rustix user would ever have a need to construct
`StatxFlags` values this way.
- No existing version of Linux increases the size of `struct statx`
beyond what rustix currently knows about.
- `struct statx` contains several spare fields, including a
`__u64 __spare3[12]` specifically for expansion, so even if a future
Linux version defines new fields, it has lots of space available before
it needs to start increasing the size of `struct statx`.
* Implement `statvfs` and `fstatvfs`.
On libc, just go with whatever the libc `statvfs` gives us. On
linux_raw, translate the fields from `statfs` in the manner of
libc implementations.
* Preserve as much of the `f_fsid` field as possible.
* Document the relationship between `statfs` and `statvfs`.
* Add a `StatVfsMountFlags` type for the `f_flag` field.
These are useful when one needs a raw descriptor and doesn't want the
overhead of doing `std::io::stdout().as_raw_fd()` or the unsafe block of
doing `rustix::io::stdout().as_raw_fd()`.
Dan Gohman