Thanks for the work done.
I can confirm it works for me now.
Terence Gomez
Le lun. 16 févr. 2026 à 12:18, Amon Ott via rsbac <rsbac(a)rsbac.org> a
écrit :
>
>
>
> ---------- Forwarded message ----------
> From: Amon Ott <ao(a)rsbac.org>
> To: rsbac(a)rsbac.org
> Cc:
> Bcc:
> Date: Mon, 16 Feb 2026 12:18:29 +0100
> Subject: [rsbac] Re: RSBAC git repo clone error - ressource limitations
> Am 16.02.26 um 09:00 schrieb Amon Ott:
> > Am 29.01.26 um 10:59 schrieb Amon Ott:
> >> Am 29.01.26 um 10:37 schrieb GOMEZ, Terence:
> >>> I can't seem to be able to clone the RSBAC git repo.
> > ...
> >>> Could you be able to fix this ?
> >>
> >> Unfortunately, this is a known issue I have not been able to fix so
> >> far. The git server at rsbac.org is still at 32 Bit and cannot cope
> >> with so many objects in a single Git repo. Getting the 64 Bit version
> >> onto the server is tricky, but I will have another look.
> >>
> >> As a workaround, please clone from git.kernel.org first and then pull
> >> from rsbac.org.
> >
> > Another workaround, just tested:
> >
> > git clone --depth 2500 git://git.rsbac.org/linux-6.18.y
> >
> > This limits the git log to 2500 entries, only going back to 2019.
> >
> > Looking at the git package again now...
>
> Got the 64 Bit git package working at rsbac.org, you can now clone all
> trees.
>
> Amon.
> --
> https://www.rsbac.org
> GnuPG: E25D2F7B0C561382570DB487DC2A69DA870FE7FF 2018-03-20
>
>
>
> ---------- Forwarded message ----------
> From: Amon Ott via rsbac <rsbac(a)rsbac.org>
> To: rsbac(a)rsbac.org
> Cc:
> Bcc:
> Date: Mon, 16 Feb 2026 12:18:29 +0100
> Subject: [rsbac] Re: RSBAC git repo clone error - ressource limitations
> _______________________________________________
> rsbac mailing list -- rsbac(a)rsbac.org
> To unsubscribe send an email to rsbac-leave(a)rsbac.org
>
Hello,
I can't seem to be able to clone the RSBAC git repo.
When trying to do so, this error comes up :
$ git clone git://rsbac.org/linux-6.18.y.git
Cloning into 'linux-6.18.y'...
remote: fatal: Out of memory, realloc failed
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
Before this error, I have "remote: Enumerating objects:" which goes up to
around 10111222.
I believe this is caused by ressource limitations on the server.
Could you be able to fix this ?
Thanks
Terence Gomez
Hi there,
RSBAC has been ported successfully to the new LTS kernel 6.18.
In my tests, 6.18 works fine. Please give it a try and report. Patches
are at https://download.rsbac.org/latestdiff/6.18/
In 6.18 I removed the RSBAC secure delete support. It has not been
maintained or well tested for a while and can make trouble in various
filesystems. With journaled file systems like ext4 it makes litte sense
anyway. This removal is going to be backported into older kernels soon.
Amon.
--
https://www.rsbac.org
GnuPG: E25D2F7B0C561382570DB487DC2A69DA870FE7FF 2018-03-20
Hi there,
RSBAC has been ported successfully to the new LTS kernel 6.12.
In my tests, 6.12 works fine. Please give it a try and report. Patches
are at https://download.rsbac.org/latestdiff/6.12/
Amon.
--
https://www.rsbac.org
GnuPG: E25D2F7B0C561382570DB487DC2A69DA870FE7FF 2018-03-20
Hi there,
the system call families getxattr() and setxattr() used to be
intercepted with requests GET_PERMISSIONS_DATA and
MODIFY_PERMISSIONS_DATA. Since extended attributes do much more than
Linux access control with ACLs, we needed a way to distinguish these
types of access.
I decided to introduce the new request types GET_XATTR and MODIFY_XATTR
for them, valid for all FD targets. The changes are in the kernel Git
repos for 6.6, 6.1, 5.15 and 5.10 as well as in the rsbac-admin repo for
administration. Older kernels remain unchanged.
Amon.
--
https://www.rsbac.org
GnuPG: E25D2F7B0C561382570DB487DC2A69DA870FE7FF 2018-03-20
Hi,
RSBAC has been ported successfully to LTS kernel 6.6. Internal kernel
changes to the Linux caps structure required new on-disk versions of all
RSBAC lists holding cap vectors.
I took the chance to default CONFIG_RSBAC_MOVETO to yes with 6.6 and
auto-adjust RC and ACL FD lists with new versions, too. Existing WRITE
right to FD targets gets amended with MOVETO during list upgrade to
avoid unexpected behaviour.
The automatic list version upgrades mean that going back to previous
kernels might show invalid lists, you need to boot with
rsbac_list_recover kernel parameter and set cap related and RC and ACL
FD values again.
In my tests, 6.6 seems to be running pretty well, please give it a try
and report.
Amon.
--
https://www.rsbac.org
GnuPG: E25D2F7B0C561382570DB487DC2A69DA870FE7FF 2018-03-20
Hello
good evening <peter(a)adamantix.org>
I just want to ask?
can i get the source code of the project you created called adamantix linux
or adamantix operating system
and sorry if my english is not good, because i can't speak english
Hi folks,
just a quick notice that RSBAC has been ported to kernel 6.1 at 5.15
state. Seems to be running fine on my test system, but please test
yourself and report here or to the bug tracker.
You get all the code at https://download.rsbac.org/latestdiff/ or
through Git at git.rsbac.org/, e.g. git://git.rsbac.org/linux-6.1.y
RSBAC has been running very well with kernel series 5.10 for a long
time, so please consider 5.10 to be the best choice for now.
Amon.
--
https://www.rsbac.org
GnuPG: E25D2F7B0C561382570DB487DC2A69DA870FE7FF 2018-03-20