Re: Python linuxfs Modules

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

Lawrence D?Oliveiro <[email protected]> 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--