aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRichard Purdie <richard.purdie@linuxfoundation.org>2020-10-08 14:56:45 +0100
committerRichard Purdie <richard.purdie@linuxfoundation.org>2020-10-08 14:56:45 +0100
commit4d4c5321ab64ad4b11f9b4ea6c76b68f8d1bc0de (patch)
tree720e2421a097c95372e31ad93ebd2df0fda95cfc
parentd6b1b13c268d7246f0288d32d6b5eccc658cff4e (diff)
downloadpseudo-4d4c5321ab64ad4b11f9b4ea6c76b68f8d1bc0de.tar.gz
pseudo-4d4c5321ab64ad4b11f9b4ea6c76b68f8d1bc0de.tar.bz2
pseudo-4d4c5321ab64ad4b11f9b4ea6c76b68f8d1bc0de.zip
pseudo.c: Stop using data from matching inodes but mismatched paths
When we see cases where the inode no longer matches the file path, pseudo notices but currently reuses the database entry. This can happen where for example, a file is deleted and a new file created outside of pseudo where the inode number is reused. Change this to ignore the likely stale database entry instead. We're seeing bugs where inode reuse for deleted files causes permission corruption. (See bug #14057 for example). We don't want to delete the database entry as the permissions may need to be applied to that file (and testing shows we do need the path matching code which handles that). I appreciate this should never happen under the original design of pseudo where all file accesses are monitored by pseudo. The reality is to do that, we'd have to run pseudo: a) for all tasks b) as one pseudo database for all of TMPDIR Neither of these is realistically possible for performance reasons. I believe pseudo to be much better at catching all accesses than it might once have been. As such, these "fixups" are in the cases I've seen in the logs, always incorrect. It therefore makes more sense to ignore the database data rather than corrupt the file permissions or worse. Looking at the pseudo logs in my heavily reused build directories, the number of these errors is staggering. This issue would explain many weird bugs we've seen over the years. There is a risk that we could not map permissions in some case where we currently would. I have not seen evidence of this in any logs I've read though. This change, whilst going against the original design, is in my view the safer option for the project at this point given we don't use pseudo as originally designed and never will be able to. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-rw-r--r--pseudo.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/pseudo.c b/pseudo.c
index d430a40..73843d0 100644
--- a/pseudo.c
+++ b/pseudo.c
@@ -705,6 +705,7 @@ pseudo_op(pseudo_msg_t *msg, const char *program, const char *tag, char **respon
(unsigned long long) msg_header.ino,
path_by_ino ? path_by_ino : "no path",
msg->path);
+ found_ino = 0;
}
}
} else {