Dear all, this is the first public announcement of scannedonly. Scannedonly is a samba VFS module that ensures that only files that have been scanned for viruses are visible and accessible to the end user. Scannedonly was developed because of scalability problems with samba-vscan: high server loads when (the same) files were requested often, and timeouts when large zip files were requested. Scannedonly comes in two parts: a samba vfs module and (one or more) daemons. The daemon scans files. If a certain file is clean, a second file is created with prefix .scanned:. The samba module simply looks if such a .scanned: file exists, and is newer than the pertinent file. If this is the case, the file is shown to the user. If this is not the case, the file is not returned in any directory listing, and cannot be opened. The samba vfs module will also tell the daemon to scan this file. More information can be found at http://olivier.sessink.nl/scannedonly/ regards, Olivier Sessink
On Sun, Dec 09, 2007 at 11:28:36AM +0100, Olivier Sessink wrote:> Dear all, > > this is the first public announcement of scannedonly. > > Scannedonly is a samba VFS module that ensures that only files that have > been scanned for viruses are visible and accessible to the end user. > > Scannedonly was developed because of scalability problems with > samba-vscan: high server loads when (the same) files were requested > often, and timeouts when large zip files were requested. > > Scannedonly comes in two parts: a samba vfs module and (one or more) > daemons. The daemon scans files. If a certain file is clean, a second > file is created with prefix .scanned:. The samba module simply looks if > such a .scanned: file exists, and is newer than the pertinent file. If > this is the case, the file is shown to the user. If this is not the > case, the file is not returned in any directory listing, and cannot be > opened. The samba vfs module will also tell the daemon to scan this file. > > More information can be found at http://olivier.sessink.nl/scannedonly/Congratulations and thanks for this ! I'd like to make sure this is kept in sync as we have to make changes to the Samba VFS going forward to add more features (NT Streams etc.). What is the best way to keep you informed as we modify the VFS layer ? Jeremy.
Peter Eser wrote:> Hi, > > only a feature suggestion: > I tried something similar as your VFS Module but never completed it. > I didn't create a second file (.scanned) for marking, but set an extended > file attribute > (getfattr, setfattr). > I also marked the unscanned files, not the scanned, so that a completely > scanned > directory is plain from any extras (nicer for backups). > I think for many files in the share the .scanned extra files can lead to > problemswhat kind of problems do you expect, can you give some more comments on that?> and you have always to hide them.true, but the module does this in the same way as non-scanned files are hidden, so there is no extra code involved.> Not all file systems have extended attributes (the most important have), so > a configuration switch would be nice. > > As said, only a feature request. > Besides your module is much appreciated. Connecting any virus scanner (or > other tools) to samba shares is needed.I might need some help to do that. I have never worked with attributes. Furthermore, right now the module is stackable (the underlying filesystem can be another samba vfs module). I don't know if samba features the getfattr and setfattr calls in the VFS layer, and it would be great to keep the module stackable. thanks for your comments, Olivier
James R Grinter wrote:> On Sun, Dec 09, 2007 at 11:28:36AM +0100, Olivier Sessink wrote: >> daemons. The daemon scans files. If a certain file is clean, a second >> file is created with prefix .scanned:. The samba module simply looks if >> such a .scanned: file exists, and is newer than the pertinent file. If >> this is the case, the file is shown to the user. If this is not the > > I have a suggestion for extending this idea. There should be a mechanism > to allow the file to be rescanned again whenever the pattern file is updated.it's possible. But realize that this happens fairly often (the clamAV database, for example, changes about 3 times each day). If your samba server has several terabytes of data, it will be continuously scanning. Before the scanning is finished, the database would be renewed already. So I'm not sure if this is a very realistic option to deploy. Can you give some examples from situations in which you would deploy this option? To implement this, the tricky thing is to tell the vfs module what the most recent database is. Currently all communucation is one-way. The vfs module tells the AV-daemon only if it hits a file that has not been scanned yet. So if the AV-daemon is offline, most of the data on the samba server is still available. If the module has to check if the scanning time is older than the AV-database, it becomes quite dependent on the AV-daemon. regards, Olivier
>>>>> "Olivier" == Olivier Sessink <lists@olivier.pk.wau.nl> writes:Olivier> user. If this is not the case, the file is not returned Olivier> in any directory listing, and cannot be opened. The samba Olivier> vfs module will also tell the daemon to scan this file. I can't help but think this might be confusing to the user, if the file unexpectedly disappears after it is created or updated. If might also confuse some programs that expect the file to exist immediately after it is created. Maybe it would be better to list the file in the directory listing still, but prevent it from being opened for reading? Write-only opens should be OK I think. -- Brian May <bam@snoopy.apana.org.au>