Great Circle Associates Majordomo-Workers
(December 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: More musings on a general access restriction mechanism
From: Jason L Tibbitts III <tibbs @ hpc . uh . edu>
Date: 31 Dec 1996 18:14:09 -0600
To: majordomo-workers @ greatcircle . com
In-reply-to: Dave Wolfe's message of Tue, 31 Dec 1996 14:31:29 -0600 (CST)
References: <199612312031.OAA16303@miaow.risc.sps.mot.com>

>>>>> "DW" == Dave Wolfe <dwolfe@risc.sps.mot.com> writes:

DW> So to keep everyone at intel.com (but only intel.com) out of a specific
DW> list, I'd have to list all possible requests? Or can I use ALL in that
DW> context?

I figured we would have groups of requests denoted by caps.  ALL would of
course designate everything.

DW> Then there's always the old Windoze .ini, AIX, or httpd file formats.
DW> No, really. Someone recently submitted an .ini config file module to
DW> CPAN.

[three options deleted]

DW> Makes *my* stomach hurt. Maybe I shouldn't have eaten lunch while
DW> thinking about this stuff. :-b

This is definitely not easy.  Fortunately we can just store it in a neutral
format and change out the parser until we figure out something that isn't
gross.

DW> Negated conditions come into play here too. How about using a keyword
DW> here too?

The original, simple idea didn't require any form of negation because the
negation was implicit in the action.  Once we want compound statements
we've got to increase the complexity quite a bit.

DW> subscribe
DW> consult OWNER
DW> NOT /\bsps\.mot\.com$/i 
DW> AND NOT /\bmcu\.mot\.com$/i
DW> OR ADDRESS_MISMATCH

I assume that there's an implicit left-association there.  You'll need a
grouping syntax if you want to allow complex expressions.  Of course, using
multiple rules you can get rid of any OR clause and by extension any NOT
clause, so the only thing that's left is AND.  So if you wanted to avoid
any complex expressions, you could do it by having multiple statements
imply an 'AND'ing.  I think this is mostly counterintuitive (and it
requires a lot of rules for simple cases) but it does have a certain
minimalist charm.

BTW, I had in mind that consult would default to either the list-owner or
majordomo-owner (for non-list-specific items).  The same with notify.

This really is a pain, and on the surface I can't begin to imagine how any
form of complex statement would be digested internally.  I recall that you
(Dave) had an idea for compiling regexp lists to execute quickly; would
this fit in?  Better yet, do you want to take a shot at turning a list of
those conditions into something that can return a true or false value?
(I'm trying to put together the config system at the moment; once I do that
I'm left with putting in the access/permission system and writing the full
list of commands.  Then it's down to bug fixing and filling in the blanks
that remain.

 - J<


References:
Indexed By Date Previous: Re: <list>.config file mod's
From: Paul Opie <opie@DigitallySpeaking.com>
Next: Re: <list>.config file mod's
From: "Roger B.A. Klorese" <rogerk@QueerNet.ORG>
Indexed By Thread Previous: Re: More musings on a general access restriction mechanism
From: Dave Wolfe <dwolfe@risc.sps.mot.com>
Next: Even more musings
From: Dave Wolfe <dwolfe@risc.sps.mot.com>

Google
 
Search Internet Search www.greatcircle.com