From Newsgroup: comp.lang.python

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Wed, 18 Mar 2026 08:04:14 -0000 (UTC), I wrote:

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:

I have committed this new AccessWrapper class to the public repo. Of
course I provide easy interconversion between AccessWrapper and the
more libacl-specific Acl wrapper class. This way I avoid having to
provide parallel equivalents for every function in the Acl class.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

------=_Part_0_92459286.1774178075336
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Lawrence D?Oliveiro <ldo@nz.invalid> Wrote in message:r

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 di= fferent kernel versions? Since some of these> APIs (like Landlock or newer = mount features) are relatively recent,> does the library provide graceful f= allbacks or just raise> NotImplementedError?Landlock in particular has been=
through about 7 versions so far, withsigns of an eighth on the way. I deal=
with that by attach API versioninfo to the relevant enums.For example, if = you look at my Python version of the ?sandboxer?sample program in the Landl= ock documentation, I get the API versionfrom the current kernel with LL_= VERSION =3D linuxpriv.get_landlock_version()then I can collect sets of avai= lable access attributes with constructslike:* All read/write operations on = both files and directories: access_file_dir_rw =3D set \ ( a=
cc for acc in ACCESS_FS if acc.min_version <=3D LL_VERSION )* R= ead-only operations on files: access_file_ro =3D set \ ( acc=
for acc in ACCESS_FS if acc.min_version <=3D LL_VERSION and acc.fil= e_op and not acc.write_op )etc.As for libacl, I?m not aware of any API=
version changes -- not in theman pages I?ve been reading so far. Similarly=
the mount API -- both goso far back that I don?t think any kernels that do= n?t implement themare 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 at= tach extra attributes that can be used to easeprogramming, as in the exampl=
es above.

Thanks for the explanation, Lawrence. The way you?ve implemented the min_ve= rsion attribute within the enums for Landlock is actually quite clever?it?s=
a clean way to handle the evolving nature of that API without cluttering t=
he user-facing code.
?However, I have to push back a bit on your assumption regarding the mount = API. While the legacy mount(2) system call is indeed a relic of the past, L= inux introduced a completely New Mount API (starting with Kernel 5.2 in 201=
9) involving fsopen(), fspick(), fsmount(), and move_mount().
?If your linuxmount module aims to be a comprehensive wrapper, ignoring the=
se newer calls might be a missed opportunity. Conversely, if you are wrappi=
ng them, then the 'universal compatibility' you mentioned doesn't quite app=
ly to older LTS kernels or enterprise environments that haven't migrated pa=
st 5.2 yet. In those cases, a simple NotImplementedError or an ENOSYS check=
would still be necessary.
?As for linuxacl, I agree?POSIX ACLs are stable enough that they?re practic= ally part of the furniture at this point.
?The extra attributes like file_op and write_op are a great touch. It defin= itely saves the developer from having to keep a copy of the man pages open = just to remember which bitmask does what.
--=20




----Android NewsGroup Reader---- https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html ------=_Part_0_92459286.1774178075336--
--- Synchronet 3.21d-Linux NewsLink 1.2