Hello,
While using learning mode for the RC module, I encounter an error when RSBAC tries to write to the disc : rsbac_write_open(): failed to open file rc_tcfd on device 08:02 for writing, error -30 rsbac_list_write_lol_buffers(): opening file rc_tcfd on device 08:02 failed with error -30! free_buffers(): Freeing buffer of size 800
I have managed to reproduce this multiple times with this setup : - with a non RSBAC kernel, I delete the entire configuration (sudo rm -rf /rsbac.dat) - I boot a first time with the RSBAC kernel, in softmode. There, I execute a script which sets up the desired configuration (about 30 roles, 25 FD types, a few PROCESS types and that's it), and I shut down the machine. - I boot a second time with RSBAC, still in softmode, with RC and AUTH learning modes activated. This is when, at some point, the error appears.
With rsbac_debug_write, I've got a little more detail : fill_lol_buffer(): Filling buffers for list of lists rc_tcfd rsbac_write_lists(): 1 lists of lists copied to buffers rsbac_list_write_lol_buffers(): write list of lists rc_tcfd on device 08:02. rsbac_write_open(): failed to open file rc_tcfd on device 08:02 for writing, error -30 rsbac_list_write_lol_buffers(): opening file rc_tcfd on device 08:02 failed with error -30! free_buffers(): Freeing buffer of size 800 rsbac_write_lists(): 4294967266 lists of lists written to disk rsbac_write_lists(): 4294967266 lists written. rsbac_write(): rsbac_write_lists() returned error -30 rsbac_write_reg(): 0 lists written.
It says 4294967266 lists were written, which is also -30 in signed binary so I guess this is how the error is passed. Anyway, before this error, there are multiple write operations that behave normally. The error repeats multiple times, always on file rc_tcfd, but in between there are other write operations that produce no error.
Terence Gomez
Hi, sorry for the late reply. I had to get some server settings fixed first.
Am 08.10.26 um 10:36 schrieb Terence Gomez:
While using learning mode for the RC module, I encounter an error when RSBAC tries to write to the disc : rsbac_write_open(): failed to open file rc_tcfd on device 08:02 for writing, error -30 rsbac_list_write_lol_buffers(): opening file rc_tcfd on device 08:02 failed with error -30! free_buffers(): Freeing buffer of size 800
I have managed to reproduce this multiple times with this setup :
- with a non RSBAC kernel, I delete the entire configuration (sudo rm -
rf /rsbac.dat)
- I boot a first time with the RSBAC kernel, in softmode. There, I
execute a script which sets up the desired configuration (about 30 roles, 25 FD types, a few PROCESS types and that's it), and I shut down the machine.
- I boot a second time with RSBAC, still in softmode, with RC and AUTH
learning modes activated. This is when, at some point, the error appears.
With rsbac_debug_write, I've got a little more detail : fill_lol_buffer(): Filling buffers for list of lists rc_tcfd rsbac_write_lists(): 1 lists of lists copied to buffers rsbac_list_write_lol_buffers(): write list of lists rc_tcfd on device 08:02. rsbac_write_open(): failed to open file rc_tcfd on device 08:02 for writing, error -30 rsbac_list_write_lol_buffers(): opening file rc_tcfd on device 08:02 failed with error -30! free_buffers(): Freeing buffer of size 800 rsbac_write_lists(): 4294967266 lists of lists written to disk rsbac_write_lists(): 4294967266 lists written. rsbac_write(): rsbac_write_lists() returned error -30 rsbac_write_reg(): 0 lists written.
It says 4294967266 lists were written, which is also -30 in signed binary so I guess this is how the error is passed. Anyway, before this error, there are multiple write operations that behave normally. The error repeats multiple times, always on file rc_tcfd, but in between there are other write operations that produce no error.
The problem behind is likely the Linux access control getting into the way, because rsbac_write_open() uses standard kernel functions. I will have a closer look soon. The 4294967266 debug output can be fixed on the fly.
The failed writes themselves are probably harmless, because the lists remain marked as dirty and get written at the next rsbacd wakeup.
Amon.