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] [day] [month] [year] [list]

Message-ID: <201010181201.53883.tvrtko.ursulin@sophos.com>
Date:	Mon, 18 Oct 2010 12:01:52 +0100
From:	Tvrtko Ursulin <tvrtko.ursulin@...hos.com>
To:	Eric Paris <eparis@...hat.com>
CC:	John Stoffel <john@...ffel.org>,
	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

On Friday 08 Oct 2010 17:41:46 Eric Paris wrote:
> On Fri, 2010-10-08 at 17:17 +0100, Tvrtko Ursulin wrote:
> > On Friday 08 Oct 2010 16:42:06 John Stoffel wrote:
> >
> > Priority is also not that great concept. I may have proposed classes or
> > something similar at some point, don't remember any more. It would be
> >
> > equivalent to having allocated priority ranges, like:
> > >1000 - pre-content
> > >=100 - access-control
> >
> > <100 - content
> >
> > Doesn't really solve ordering inside groups so maybe we do not need
> > priorities at all just these three classes?
>
> I originally thought of trying to enumerate the types of users and came
> up with the same 3 you did.  Then I thought it better to give a general
> priority field which we could indicate in documentation something like
> those 3 classes (exactly like you did above).  I don't want to hard code
> some limited number of types of users into the interface. (ok it's going
> to limited, I was thinking 8 bits, but maybe others think we need more?)
>
> As an extreme example going with 3 fixed type of users (and thus
> equivalently only 3 priorities) would not allow for hierarchies of
> hierarchical storage managers.  What if priority MAX only brought in
> enough info for priority MAX-1 to bring in the real file?  If they had
> to share the single 'pre-content' priority we have another ordering
> problem.

I think I am fine with priorities if we make these three ranges documented.

Ordering between ranges, like in your chained HSM setup, would then be
sysadmin's responsibility but those setups look esoteric enough to think we
could get away with it. More importantly, I really do not see an automatic
solution which would solve all imaginable (more or less crazy) setups one
could come up with and priorities solve all normal ones plus giving some more
options than having only three classes.

If you go with 8 bits, you could even have classes plus priorities. Like
having low bits for in-class priority and then high two or three for class
(three if with a single bit set in class field implementation would be more
efficient). I do not see any usability advantage of this scheme though, it
just may enable an implementation with less decisions based on arbitrary
numbers.

Tvrtko

Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--
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/