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
rCLosrCY module in the standard Python library, but most donrCOt. 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 DrCOOliveiro 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 rCLosrCY module in the standard Python library, but most donrCOt. 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 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.21f-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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 3/17/2026 2:33 AM, Lawrence DrCOOliveiro 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 rCLosrCY module in the standard Python library, but most donrCOt. 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

This looks like outstanding programming.

Got any users or feedback?
--- Synchronet 3.21f-Linux NewsLink 1.2