TALPA strides forward [LWN.net]

TALPA strides forward

Posted Aug 28, 2008 4:45 UTC (Thu) by jzbiciak (guest, #5246)
In reply to: TALPA strides forward by jwb
Parent article: TALPA strides forward

If an actual virus scanner is included in the kernel, sure. But the hooks themselves sound reasonable for other purposes, such as hierarchical storage management. I wouldn't throw the baby out with the bathwater.

I do agree, though, that scanning Samba shares for Windows viruses sounds like a userspace problem.

to post comments

TALPA strides forward

Posted Aug 28, 2008 6:42 UTC (Thu) by drag (guest, #31333) [Link] (8 responses)

Yes.

Look, ignore all the 'windoze' and 'ignorant users' for now.

What this allows to do is active scanning of files. Not necessarily for viruses, but for any reason you can think of.

-------------
Now we have Clamav, right? Well Clamav is a passive scanning program. Meaning it can only scan files that we direct at it to scan.

A active scanner, on the other hand, is designed so that it deals with files on a automated manner based on file system events.

This is all that they want to do, at this point. On a given file system event, pause the access, and alert a third party to the event, redirect data as necessary, and then allow or deny access based on that third party.

Virus scanning, at this point, doesn't even enter into it. The criteria or data logging facilities can be used for anything.

It's a bit of a solution in search of a problem, but I wouldn't be suprised if somebody comes up with something clever to do with it. It's a bit like extended acls... sure for most functions you can figure out how to do a decent job with rwx/ugo, but you'll run into situations were the older access controls won't work effectively without a lot of kludges.

At the very least when setting up a Windows network file server/web server/email server/etc you can vastly improve performance and security by only scanning files as they change, real-time, instead of periodically scanning the entire share. Instead of stumbling onto a virus a hour after it's been written to your server you can have a 'ok' chance of intercepting it and logging the machine.

TALPA strides forward

Posted Aug 28, 2008 6:54 UTC (Thu) by drag (guest, #31333) [Link] (7 responses)

Ok.. Here is one application.

How about tying a revision control system into it, something like 'git'? Instead of just having formal commits, you can have smaller revisions of secondary importance of each and every time you write to a file.

Maybe make it so that it's possible that you could colaberate with other people real-time... so that you could have your local copy, but have it alert you if a file your writing too has already been changed by another person. So that way you would not rely on a central server or system to keep a 'fence' or whatever.. you just write a file and notifications are sent out quickly.

Something.

TALPA strides forward

Posted Aug 28, 2008 10:29 UTC (Thu) by NAR (subscriber, #1313) [Link] (2 responses)

I believe the filesystem used by ClearCase does something similar.

TALPA strides forward

Posted Aug 28, 2008 15:50 UTC (Thu) by pflugstad (subscriber, #224) [Link] (1 responses)

Clearcase requires explicit check-in/out else others won't see your changes. At least if you're in different views. And if multiple people are working in the same view, you should be shot.

TALPA strides forward

Posted Aug 28, 2008 16:01 UTC (Thu) by NAR (subscriber, #1313) [Link]

I meant the you could have your local copy, but have it alert you if a file your writing too has already been changed by another person part - the dynamic view in ClearCase lets me have a local copy (as long as I've checked out the file) and will alert at checkin that the file was changed. The other (not checked out) files are automatically updated (i.e. colaberate with other people real-time).

On the other hand, even vim alerts me, if an opened file is changed on the disk...

TALPA strides forward

Posted Aug 28, 2008 10:55 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

That job is surely better done with FUSE.

Just about the only thing TALPA can do that FUSE can't is run over areas
of the system, like /usr or /, where frequent transitions to a userspace
filesystem would be damaging to performance.

TALPA strides forward

Posted Aug 28, 2008 23:51 UTC (Thu) by dlang (guest, #313) [Link]

the problem with fuse is the performance

but also, unless fuse implements similar hooks you would need to have a fuse layer for each scanner tool, and that will make the performance problems even worse.

SCM in the filesystem?

Posted Aug 31, 2008 2:40 UTC (Sun) by vonbrand (guest, #4458) [Link] (1 responses)

Sure, at first sight the idea of "each change is a commit" sounds sensible, but if you have ever worked with some kind of fine-grained (local like RCS, or distributed like git) SCM, you soon discover that commits must record meaningful changes. Not each time I decide to save a file in the editor "just in case" (or, much worse, that the editor decides that there have been enough changes to write out a snapshot) does make sense as a meaningful point in history. Most commits are coordinated changes to several files (something of which you are painfully aware when using RCS).

SCM in the filesystem?

Posted Mar 25, 2009 18:17 UTC (Wed) by mrshiny (guest, #4266) [Link]

It would be useful to automatically put /etc under source control using a tool like this. Every save in /etc IS a commit on my system.