[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apparmor-general
Subject:    Re: [Apparmor-general] apparmor svn history / tomoyo lms approach
From:       John Johansen <jjohansen () suse ! de>
Date:       2008-10-28 21:39:51
Message-ID: 490786A7.8030800 () suse ! de
[Download RAW message or body]

Arkadiusz Miskiewicz wrote:
> On Thursday 23 of October 2008, John Johansen wrote:
>> Arkadiusz Miskiewicz wrote:
>>> Is there another repo beside svn? apparmor svn repository has no history.
>>> Just someone drops bunch of new patches :-/
>> there used to be, but there mostly isn't anymore.  The history portion
>> of the svn is admittedly terrible.
>>
>> The kernel portion is particularly bad as its done against a quilt
>> series that is tracked across and merged from a couple of svn's.  With
>> branching of different kernel versions not happening correctly.
>>
>>> I'm using for-kernel/2.6.25 and I wonder if there were any important
>>> fixes but... finding that without history is a big problem unfortunately.
>> There are in fact some fixes that haven't been applied to the 2.6.25
>> branch but I haven't had time to update the 2.6.25 branch yet.  The
>> update will happen soon.
> 
> Nice.
> 
> I have some wierd issues with files being corrupted or disappearing from 
> filesystem (xfs) on 2.6.25.18 (very, very rarely but still happening).
> 
> apparmor is biggest patch that does many things to vfs layer and I wonder if 
> there are any known problems which could be visible as such corruptions in 
> apparmor patch for 2.6.25?
> 
No, this type of corruption is not a known problem and it is very
unlikely to be caused by the AppArmor patches.  The problems that
usually surface are when a mistake has been made and a bad pointer gets
passed down usually resulting in an oops message.

The AppArmor vfs patches take existing vfs information (vfsmnt, and some
times file) and pass it down to the LSM layer so that an LSM module can
use the extra information.

The changes do not affect the data read/write paths of files, it only
affects the permission checks.  With that said I can conceive of a few
possible situations where some type of file corruption or file loss
could appear depending on how the application is written.

For file loss all that is needed is the application to split itself
between a couple of processes that have different profiles.  Where one
process perhaps moves/removes a file and expects the other process to
write it, but the other process does not have permission.  This will
result in a reject to the application and a log message.

For file corruption the scenario is similar but relies on a file handle
being passed.  In this case when the second process goes to write to the
open file its write fails.  Leaving the file with the contents it had,
under some applications this could result in a partial update of a file
which might appear as corruption.  This will also result in a reject
message in the log.

There is of course always the chance that there is a bad pointer passed
down and it doesn't cause an oops but results in updating the files data
with garbage, but it is not likely that this would happen consistently
without causing the occasional oops.




_______________________________________________
Apparmor-general mailing list
Apparmor-general@forge.novell.com
http://forge.novell.com/mailman/listinfo/apparmor-general
[prev in list] [next in list] [prev in thread] [next in thread]