[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49603B15.9080701@gmail.com>
Date: Sat, 03 Jan 2009 20:29:09 -0800
From: "Justin P. Mattock" <justinmattock@...il.com>
To: Jamie Lokier <jamie@...reable.org>
CC: Daniel Phillips <phillips@...nq.net>, tux3@...3.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [Tux3] Tux3 report: A Golden Copy
Jamie Lokier wrote:
> Justin P. Mattock wrote:
>
>> Thats some crazy stuff!! and just think most of it is
>> simply magnets.(but more complicated than that)
>>
>>> One feature we are kicking around to make life easier for SELinux:
>>> sometimes the filesystem can run while SELinux is not running, and
>>> security labels will be wrong when SELinux re-enters the picture. We
>>> have in mind to provide a persistent log of filesystem events that the
>>> security system can attach to on startup and find out what went on in
>>> its absence.
>>>
>>>
>>>
>> That sounds nice:
>>
>> find out what went on in
>> its absence.
>>
>
> That sounds like a feature Windows had for many years now, (since
> Windows 2000?). It complements the Windows equivlant of
> dnotify/inotify/fsnotify.
>
> It's used for file indexing too (think equivalent to Spotlight,
> Beagle, etc.), and other types of security scanning (think equivalent
> to Tripwire).
>
> I wonder why the people writing file indexing tools for Linux never
> made a fuss about this. Inotify is ok for indexing, but means quite a
> few minutes of intensive disk activity after each boot to rescan /home.
>
> -- Jamie
>
>
Thanks for the info.
What about apps like git?
i.g. when changing a file
it knows that the file was changed;
(not sure how it works, remembers
the size or something like that);
With the file indexing is it smart(like git) enough
to know that the data was changed, or does it just
go by the name. With running SELinux I'm able to
change wpa_supplicant.conf with different ssid's
and keys and there wont be a denial, but If I change
out libflashplayer.so with a newer or same plugin
I will receive a denial. (bad example but all I could think of)
So it does have an idea to when a file is changed.
personally having mechanisms know exactly when
a file was changed internally is nice, this way
you at least are aware
that something has changed, and you know where.
regards;
Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists