python_linuxfs <https://gitlab.com/ldo/python_linuxfs> is a set of
Python modules providing higher-level wrappers around various
Linux-specific system APIs. Some of these already have support in the
?os? module in the standard Python library, but most don?t. Even for
the ones that do, I think my wrappers are nicer to use, because they
avoid the requirement for working with bitmasks and use sets of
symbolic bit enums instead (with easy conversions between both forms).

The package is split into five modules:

* linuxfs -- file/directory functions and common utilities used by
other modules
* linuxacl -- access-control-list functions
* linuxmount -- enhanced Linux mount API
* linuxpriv -- privilege control, i.e. the Linux landlock API
* linuxproc -- process control: prctl (selected), pidfd,
signalfd and signal mask sets, namespaces

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 17.03.2026 09:33, Lawrence D?Oliveiro wrote:

python_linuxfs <https://gitlab.com/ldo/python_linuxfs> is a set of
Python modules providing higher-level wrappers around various
Linux-specific system APIs. Some of these already have support in the
?os? module in the standard Python library, but most don?t. Even for
the ones that do, I think my wrappers are nicer to use, because they
avoid the requirement for working with bitmasks and use sets of
symbolic bit enums instead (with easy conversions between both forms).

The package is split into five modules:

* linuxfs -- file/directory functions and common utilities used by
other modules
* linuxacl -- access-control-list functions
* linuxmount -- enhanced Linux mount API
* linuxpriv -- privilege control, i.e. the Linux landlock API
* linuxproc -- process control: prctl (selected), pidfd,
signalfd and signal mask sets, namespaces

Interesting approach. Regarding the linuxacl and linuxmount modules: how
do you handle compatibility across different kernel versions? Since some
of these APIs (like Landlock or newer mount features) are relatively
recent, does the library provide graceful fallbacks or just raise NotImplementedError?

Using sets of enums instead of bitmasks is definitely 'The Pythonic
Way'. It makes the code much more self-documenting.

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 17 Mar 2026 14:30:42 +0300, Oguz Kaan Ocal wrote:

Regarding the linuxacl and linuxmount modules: how do you handle compatibility across different kernel versions? Since some of these
APIs (like Landlock or newer mount features) are relatively recent,
does the library provide graceful fallbacks or just raise NotImplementedError?

Landlock in particular has been through about 7 versions so far, with
signs of an eighth on the way. I deal with that by attach API version
info to the relevant enums.

For example, if you look at my Python version of the ?sandboxer?
sample program in the Landlock documentation, I get the API version
from the current kernel with

LL_VERSION = linuxpriv.get_landlock_version()

then I can collect sets of available access attributes with constructs
like:

* All read/write operations on both files and directories:

access_file_dir_rw = set \
(
acc for acc in ACCESS_FS
if acc.min_version <= LL_VERSION
)

* Read-only operations on files:

access_file_ro = set \
(
acc for acc in ACCESS_FS
if acc.min_version <= LL_VERSION and acc.file_op and not acc.write_op
)

etc.

As for libacl, I?m not aware of any API version changes -- not in the
man pages I?ve been reading so far. Similarly the mount API -- both go
so far back that I don?t think any kernels that don?t implement them
are still in any kind of support. Correct me if I?m wrong. ;)

Using sets of enums instead of bitmasks is definitely 'The Pythonic
Way'. It makes the code much more self-documenting.

More than that, I can attach extra attributes that can be used to ease programming, as in the examples above.

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lawrence D?Oliveiro <ldo@nz.invalid> writes:

python_linuxfs <https://gitlab.com/ldo/python_linuxfs> is a set of
Python modules providing higher-level wrappers around various
Linux-specific system APIs. Some of these already have support in the
?os? module in the standard Python library, but most don?t.

Nice. There were a few things like this that were missing for years. I
was going to suggest adding them to your modules, but it looks like
they've finally made it to the Python world elsewhere.

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 17 Mar 2026 23:28:26 -0700, Paul Rubin wrote:

There were a few things like this that were missing for years. I was
going to suggest adding them to your modules, but it looks like
they've finally made it to the Python world elsewhere.

Someone else had already done a wrapper for the ACL functions <https://github.com/iustin/pylibacl>. However, I feel they expose too
much of the underlying libacl details -- for example, I don?t see the
point in separating a ?permset? object from its associated ACL entry,
since the two are always tied together anyway. Also they have written
an extension module in C, whereas mine is a pure-Python implementation
using ctypes. As for what difference it makes, consider that they need
about 1800 lines of code, whereas I can provide equivalent
functionality in about half that.

Actually, I have a plan to go further. I have figured out that the
contents of an ACL can be expressed most naturally as a Python object
with the following components:

* a user_access array, indexed by the USERCLASS enum (with values
USER, GROUP and OTHER), with each value being a set of the PERM
enum (with the expected values READ, WRITE and EXECUTE); put these
together, and you get the usual *nix mode value.
* two dictionaries, ?users? and ?groups?, keyed by user and group
IDs respectively, with the values being sets of PERM as before.
You have the usual Python dictionary operations to
access/iterate/add/modify/remove entries in these -- no need
to invent new API-specific ones.
* a mask value, being yet another set of PERM.

Working at that level, it seems to me, would be easier than any simple
wrapper around libacl.

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)