Skip to content
Snippets Groups Projects
user avatar
Colin Walters authored
I was working on rpm-ostree unified core, and hit the fact that
`glnx_file_copy_at()` had the same bug with `fsetxattr()` and files whose mode
is <= `0400` (e.g. `000` in the case of `/etc/shadow`) that libostree did a
while ago.  Basically, Linux currently allows `write()` on non-writable open files
but not `fsetxattr()`.  This situation is masked for privileged (i.e.
`CAP_DAC_OVERRIDE`) code.

Looking at this, I think it's cleaner to convert to `O_TMPFILE` here,
since that code already handles setting the tmpfile to mode `0600`.  Now,
this *is* a behavior change in the corner case of existing files which
are symbolic links.  Previously we'd do an `open(O_TRUNC)` which would follow
the link.

But in the big picture, I think the use cases for `open(O_TRUNC)` are really
rare - I audited all callers of this in ostree/rpm-ostree/flatpak, and all of
them will be fine with this behavior change. For example, the ostree `/etc`
merge code already explicitly unlinks the target beforehand. Other cases like
supporting `repo/pubring.gpg` in an ostree repo being a symlink...eh, just no.

Making this change allows us to convert to new style, and brings all of the
general benefits of using `O_TMPFILE` too.
673f48f6
History

libglnx is the successor to libgsystem: https://git.gnome.org/browse/libgsystem

It is for modules which depend on both GLib and Linux, intended to be used as a git submodule.

Features:

  • File APIs which use openat() like APIs, but also take a GCancellable to support dynamic cancellation
  • APIs also have a GError parameter
  • High level "shutil", somewhat inspired by Python's
  • A "console" API for tty output
  • A backport of the GLib cleanup macros for projects which can't yet take a dependency on 2.40.

Why?

There are multiple projects which have a hard dependency on Linux and GLib, such as NetworkManager, ostree, flatpak, etc. It makes sense for them to be able to share Linux-specific APIs.

This module also contains some code taken from systemd, which has very high quality LGPLv2+ shared library code, but most of the internal shared library is private, and not namespaced.

One could also compare this project to gnulib; the salient differences there are that at least some of this module is eventually destined for inclusion in GLib.

Porting from libgsystem

For all of the filesystem access code, libglnx exposes only fd-relative API, not GFile*. It does use GCancellable where applicable.

For local allocation macros, you should start using the g_auto macros from GLib. A backport is included in libglnx. There are a few APIs not defined in GLib yet, such as glnx_fd_close.

gs_transfer_out_value is replaced by g_steal_pointer.

Contributing

Currently there is not a Bugzilla product - one may be created in the future. You can submit PRs against the Github mirror:

https://github.com/GNOME/libglnx/pulls

Or alternatively, email one of the maintainers directly.