Thread (44 messages) 44 messages, 10 authors, 2019-06-12

Re: [RFC][PATCH 00/10] Mount, FS, Block and Keyrings notifications [ver #3]

From: Andy Lutomirski <luto@amacapital.net>
Date: 2019-06-06 21:54:38
Also in: keyrings, linux-block, linux-fsdevel, linux-security-module, linux-usb, lkml

On Jun 6, 2019, at 2:17 PM, David Howells [off-list ref] wrote:

Andy Lutomirski [off-list ref] wrote:
quoted
quoted
quoted
You are allowing arbitrary information flow between T and W above.  Who
cares about notifications?
I do. If Watched object is /dev/null no data flow is possible.
There are many objects on a modern Linux system for which this
is true. Even if it's "just a file" the existence of one path
for data to flow does not justify ignoring the rules for other
data paths.
Aha!

Even ignoring security, writes to things like /dev/null should
probably not trigger notifications to people who are watching
/dev/null.  (There are probably lots of things like this: /dev/zero,
/dev/urandom, etc.)
Even writes to /dev/null might generate access notifications; leastways,
vfs_read() will call fsnotify_access() afterwards on success.
Hmm. I can see this being an issue, but I guess not with your patch set.
Whether or not you can set marks on open device files is another matter.
quoted
David, are there any notification types that have this issue in your
patchset?  If so, is there a straightforward way to fix it?
I'm not sure what issue you're referring to specifically.  Do you mean whether
writes to device files generate notifications?
I mean: are there cases where some action generates a notification but does not otherwise have an effect visible to the users who can receive the notification. It looks like the answer is probably “no”, which is good.

Casey, is this good enough for you, or is there still an issue?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help