Message ID | 20220428065354.27605-1-lersek@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | selinux_restorecon(3), setfiles(8): skip relabeling errors | expand |
A couple of comments: I'm not clear from the patch series what the difference is between an error which ignored (and counted) and an error that would actually stop setfiles immediately. With setfiles -C, will all errors now be counted and cause setfiles to exit with 1, or will some errors still be fatal (exit with 255)? Why on earth is setfiles originally calling exit(-1) at all?! I didn't even know that was allowed. I wrote a test program and this does indeed cause the exit status to be 255 (because the status is &-ed with 0xff). Never seen a program before calling exit(-1). Rich.
On 04/28/22 11:22, Richard W.M. Jones wrote: > > A couple of comments: > > I'm not clear from the patch series what the difference is between an > error which ignored (and counted) and an error that would actually > stop setfiles immediately. The difference is: with the new flag, we count and ignore exactly those errors that would abort the processing (the file tree walk) in case SELINUX_RESTORECON_ABORT_ON_ERROR were specified. This is based on Petr's comments in RHBZ#1794518. The whole idea is: stick with non-aborting, but *also* don't fail the whole function in case you had aborted with ABORT_ON_ERROR. Because right now, even though we don't abort, we still fail the whole function. > With setfiles -C, will all errors now be > counted and cause setfiles to exit with 1, or will some errors still > be fatal (exit with 255)? The latter, definitely. > Why on earth is setfiles originally calling exit(-1) at all?! I > didn't even know that was allowed. I wrote a test program and this > does indeed cause the exit status to be 255 (because the status is > &-ed with 0xff). Never seen a program before calling exit(-1). I noticed that immediately, but that's not something I want to get into... ;) Laszlo