my distaste for readers.conf grows

Brandon Hume hume at Den.BOFH.Halifax.NS.Ca
Tue Nov 16 03:09:30 UTC 1999

> unmitigated disaster, and all the feedback I've seen is making me
> wish I'd never implemented it in the first place.  Does *anyone*
> (besides me) actually prefer it to the old format?

I like some aspects of readers.conf... for instance, the multiple access
realms which may or may not intersect, and the ability to call external
programs.  That stuff is beautiful.

The main problems I run into are with the auth realms and how they relate
to the access realms.  Like you said, "key" can be used to associate auth
and access, but doesn't have to be, which I find ambiguous.  And if the 
key and default keywords direct to different access realms, what happens?
Or is it even an issue?

It might be the same case as a lot of other stuff in the new INN, simply a
lack of documentation.  But I find I have a hard time grasping it without
knowing the exact flow of authentication.  And the code I find a bit.. uh...
twisted (sorry), so I don't gain a lot of insight from there.

In my own opinion, which is that of a person not involved in INN's development
and thus may be worth no more than that of an intoxicated hamster, it'd be
nice if each auth realm had a "pass" and "fail" keyword, with an access
realm name (or key, or whatever) as an argument.  If you pass the auth tests,
you get THIS access, if you don't, you get THAT access... no guessing.  Maybe
a keyword to say whether you pass by default or fail by default.

And then, of course, if you wanted to get really funky you could have pass
or fail "sub"-stanzas, with pointers to other auth realms which would
modify access further, building up layers of privledge.

	auth "<default>" {
		host: "*"
		authdefault: fail

		pass {
			access: "<generic_dal>"
			next-auth: "<check_labs>"
		fail {
			access: "<outside_user>"

	auth: "<check_labs>" {
		host: "lab*"
		authdefault: fail
		pass {
			access: "<lab_access>"
		fail {
			access: "<staff_access>"

A bit long, and I think getting way off track from your "does anybody like
it" yes-or-no question, but I hope it adequately illustrates how I tend to
think through authentication (and expresses some wishes of mine besides...
I think I'll probably implement this on my own no matter that the real INN
comes out with... :) )

Brandon Hume    - hume -> BOFH.Halifax.NS.Ca, http://WWW.BOFH.Halifax.NS.Ca/
                       -> Solaris Snob and general NOCMonkey

More information about the inn-workers mailing list