> I really think that we need to avoid trying to have a single 'known good' 
quoted text
> flag/generationnrwith the inode.

I don't think we should have anything in the inode. We don't want to
bloat inode objects for this cornercase.

quoted text
> if you store generation numbers for individual apps (in posix attributes 
> to pick something that could be available across a variety of 
> filesystems), you push this policy decision into userspace (where it

Agreed
 
quoted text
> 1. define a tag namespace associated with the file that is reserved for 
> this purpose for example "scanned-by-*"

What controls somewhat writing such a tag on media remotely ? Locally you
can do this (although you are way too specialized in design - an LSM hook
for controlling tag setting or a general tag reservation sysfs interface
is more flexible than thinking just about scanners.

quoted text
> 2. have an kernel option that will clear out this namespace whenever a 
> file is dirtied

That will generate enormous amounts of load if not carefully handled.

quoted text
> 3. have a kernel mechanism to say "set this namespace tag if this other 
> namespace tag is set" (this allows a scanner to set a 'scanning' tag when 
> it starts and only set the 'blessed' tag if the file was not dirtied while 

User space problem. Set flags 'dirty', then set bit 'scanning'
clear 'dirty' then clear 'scanning' when finished. If the dirty flag got
set while you were scanning it will still be set now you've cleared you
scanning flag. Your access policy depends upon your level of paranoia (eg
"dirty|scanning == BAD")

quoted text
> programs can set the "scanned-by-*" flags on that the 'libmalware' library 

We've already proved libmalware doesn't make sense

quoted text
> L. the fact that knfsd would not use this can be worked around by running 
> FUSE (which would do the checks) and then exporting the result via knfsdw

Not if you want to get any work done.

quoted text
> what did I over complicate in this design? or is it the minimum feature 
> set needed?
> 
> are any of the features I list impossible to implement?

Go write it and see, provide benchmarks ?  I don't see from this how you
handled shared mmap ?


--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/