linux-kernel - Re: Linux 2.6.36-rc7

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Oct 2010 12:54:06 -0400
From:	"John Stoffel" <john@...ffel.org>
To:	Tvrtko Ursulin <tvrtko.ursulin@...hos.com>
Cc:	John Stoffel <john@...ffel.org>, Eric Paris <eparis@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"agruen@...e.de" <agruen@...e.de>
Subject: Re: Linux 2.6.36-rc7

>>>>> "Tvrtko" == Tvrtko Ursulin <tvrtko.ursulin@...hos.com> writes:

Tvrtko> On Friday 08 Oct 2010 16:42:06 John Stoffel wrote:
>> >>>>> "Eric" == Eric Paris <eparis@...hat.com> writes:
Eric> I will tell you that the way I envision it working (and being
Eric> backwards compatible) is that priority 0 is the last thing to be
Eric> serviced.  If 2 things register at the same priority the order
Eric> between them getting events is unpredictable.  So when an HSM
Eric> uses the interface it would use the highest priority.  An AV
Eric> vendor might use (highest priority / 2) while normal inotify
Eric> like listeners would all be happy using priority 0.
>> 
>> Ugh, I'd prefer that priority 0 is first (highest), but I can see how
>> that would make ABI problems, assuming we don't punt on releasing the
>> ABI now.
>> 
>> So if the order is undefined now, that's not good.  Well... maybe it's
>> acceptable, but I can see all kinds of problems cropping up.
>> Hopefully they're processed in order of notifier creation instead.  So
>> if I insert a notifier, anyone who inserts a notifier after me gets
>> serviced after my notifier gets run.  That would seem to be the
>> logical and sane semantics to use here.
>> 
>> Again, I'm really approaching this as a SysAdmin who'd love to use
>> this in an HSM environment, so ordering is a *key* requirement.

Tvrtko> Ordering by time of registration? I thought of that but it
Tvrtko> falls flat once any service needs to restart or be restarted.

Yup, it can fail, esp if you have indexing before the HSM
retrieval... :]  That could lead to all kinds of silliness.

But then again, how *serious* is it when it does fail?  For example,
we use CommVault at work on Netapps to do HSM for some data.  CV
leaves a little stub file holding the key to the content to be
restored, and a note for the end user saying "Don't mess with this
file, it's a pointer to your data.  Call your SysAdmin if you see
this..."

So that's one way of approaching the error handling case.

Tvrtko> Priority is also not that great concept. I may have proposed
Tvrtko> classes or something similar at some point, don't remember any
Tvrtko> more. It would be equivalent to having allocated priority
Tvrtko> ranges, like:

Tvrtko> 1000 - pre-content
Tvrtko> =100 - access-control
Tvrtko> <100 - content

Umm, why is there only one value for the access-control part?  Are you
saying there should only be one program to decide on access control?
Shouldnt' there be more?   So I think you're classes are just passed
in by the notifier setup call:

   flags = FANOTIFY_PRE_CONTENT & FANOTIFY_EXCLUSIVE;
   add_notifier(filesystem,flags,&hook);

   flags = ACCESS & SUFFICIENT;
   add_notififier(filesystem,flags,&hook);

And you'd have flags like:

    PRE_ACCESS 	     1
    ACCESS	     2
    POST_ACCESS	     4
    EXCLUSIVE	     8
    SUFFICIENT	     16	/* Passing this means all ACCESS is allowed */
    		        /* even with other ACCESS notifiers in the
			chain */

so say where in the process you need to be.  The EXCLUSIVE flag means
we want to be the only one doing this and to bail if someone else is
already registered.  

Tvrtko> Doesn't really solve ordering inside groups so maybe we do not
Tvrtko> need priorities at all just these three classes?

Ordering is a key thing.  In most cases, you don't care, but for some
cases you really do care.  

Maybe we should take some of the ideas used by PAM for ordering to
used as a basis?  

John
--
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/