The inode security blob should never be NULL in a situation where
any of the LSM hooks depend on it. The only ways that could possibly
happen are if an inode is allocated before the LSM infrastructure is
initialized or if the system is out of memory when an inode is allocated
and there are no entries in the cache. As the code says, "unlikely" and
probably in a system failure state already.
Smack tries to be pedantic about having data set up properly. So is the
LSM infrastructure management of inode blobs. I have not identified a case
where you should be able to get to an LSM hook requiring the security blob
if the blob is NULL. If initializing the inode fails it should be impossible
to use the inode thereafter.
Also, I wonder in which situation will the inode->i_security be NULL?
The inode->i_security should never be NULL if the inode has been
initialized. Any LSM hook that finds this to be NULL has probably
identified a bug elsewhere in the system.
Thanks, and I hope I could make my contributions to LSM soon.
Excellent. Please, tell us more about what you're proposing.
The inode security blob should never be NULL in a situation where
any of the LSM hooks depend on it. The only ways that could possibly
happen are if an inode is allocated before the LSM infrastructure is
initialized or if the system is out of memory when an inode is allocated
and there are no entries in the cache. As the code says, "unlikely" and
probably in a system failure state already.
Smack tries to be pedantic about having data set up properly. So is the
LSM infrastructure management of inode blobs. I have not identified a case
where you should be able to get to an LSM hook requiring the security blob
if the blob is NULL. If initializing the inode fails it should be impossible
to use the inode thereafter.
quoted
Also, I wonder in which situation will the inode->i_security be NULL?
The inode->i_security should never be NULL if the inode has been
initialized. Any LSM hook that finds this to be NULL has probably
identified a bug elsewhere in the system.
Thanks for the quick reply. If I understand correctly, I should follow the first pattern if I want to use the inode blob.
quoted
Thanks, and I hope I could make my contributions to LSM soon.
Excellent. Please, tell us more about what you're proposing.
My work will be related to the IPE LSM we proposed before. For the inode blob, we want to use it to save some file data like FSVerity signature so that the LSM can define policy based on that data.
From: James Morris <jmorris@namei.org> Date: 2021-01-12 04:39:47
On Mon, 11 Jan 2021, Fan Wu wrote:
quoted
The inode->i_security should never be NULL if the inode has been
initialized. Any LSM hook that finds this to be NULL has probably
identified a bug elsewhere in the system.
Thanks for the quick reply. If I understand correctly, I should follow the
first pattern if I want to use the inode blob.
I don't think it's necessary, and if there's a race somewhere causing
this, we shouldn't just paper it over.
Btw, none of the existing cases are even using WARN_ON or similar to let
the user know there's a problem.
--
James Morris
[off-list ref]
On Tue, Jan 12, 2021 at 5:39 AM James Morris [off-list ref] wrote:
On Mon, 11 Jan 2021, Fan Wu wrote:
quoted
quoted
The inode->i_security should never be NULL if the inode has been
initialized. Any LSM hook that finds this to be NULL has probably
identified a bug elsewhere in the system.
Thanks for the quick reply. If I understand correctly, I should follow the
first pattern if I want to use the inode blob.
I don't think it's necessary, and if there's a race somewhere causing
this, we shouldn't just paper it over.
Btw, none of the existing cases are even using WARN_ON or similar to let
the user know there's a problem.
I agree, for BPF, I will send a patch to switch to using WARN_ON_ONCE or just
get rid of the check altogether.