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: Dave Wolfe <dwolfe @ risc . sps . mot . com>
Date: Tue, 31 Dec 1996 14:31:29 -0600 (CST)
To: tibbs @ hpc . uh . edu (Jason L Tibbitts III)
Cc: majordomo-workers @ greatcircle . com
In-reply-to: <ufau3p2muyh.fsf@sina.hpc.uh.edu> from "Jason L Tibbitts III" at Dec 31, 96 12:26:14 pm
Reply-to: Dave Wolfe <david_wolfe @ risc . sps . mot . com>

[ Jason L Tibbitts III writes: ]
> 
> >>>>> "DW" == Dave Wolfe <dwolfe@risc.sps.mot.com> writes:
> 
> DW> If you use GLOBAL to set defaults, which is what seems to be happening,
> DW> the ordering gets a little confusing.
> 
> It isn't for defaults, it's for things that don't make sense to set on a
> per-list basis.

Of course! Then the obvious extension is a 'set*onfig ALL access_table'
at the end of the GLOBAL and list-specific rules to set non-standard
defaults for anything not specifically set.

> although the ill-named access, which is intended to control whether or
> not Majordomo even responds to the mail, isn't a per-list value.

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

set*onfig moto_list access_table << END
ALL
ignore notify=OWNER
/.*\bintel\.com$/i
END

Having to list all the actions could suffer a lot of breakage when a
new request is added.

[ Problems with list delimiters, multiple line fields, continuation lines. ]

> That's the problem with the syntax I'm proposing.  It's too dependent on
> whitespace and line counts.  Perhaps something that looks more like a
> header:

[ deleted ]

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

.ini:
-----
[paragraph identifier]
keyword=value
...

AIX:
-----
* standard c compiler
xlc:    use        = DEFLT
        crt        = /lib/crt0.o
        mcrt       = /lib/mcrt0.o
        gcrt       = /lib/gcrt0.o
        libraries  = -lc
        proflibs   = -L/lib/profiled,-L/usr/lib/profiled
        options    = -H512,-T512,-D_ANSI_C_SOURCE,-qansialias
[...]
* common definitions
DEFLT:  xlc        = /usr/lpp/xlc/bin/xlcentry
        as         = /bin/as
        ld         = /bin/ld
        options    = -D_IBMR2,-D_AIX,-D_AIX32,-bhalt:4
        ldopt      = "b:o:e:u:R:H:Y:Z:L:T:A:V:k:j:"

httpd:
-----
AuthUserFile /xxx/xxx/httpd/permit/.htpasswd
AuthGroupFile /xxx/xxx/httpd/permit/.htgroup
AuthName ByPassword
AuthType Basic

<Limit GET POST PUT>
require user dwolfe
</Limit>


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

> Another thing to consider is what happens to multiple regexps:
> 
> deny
> /^dwolfe/i
> /dave\.wolfe/i
> 
> Are they 'or'ed or 'and'ed? 'or' makes more sense for this example,

Especially considering that 'and' makes *no* sense...

> but if we have conditions other than addresses:
> 
> subscribe
> consult  (defaults to list-owner)
> /.*aol\.com$/i
> SUBSCRIPTION_ADDRESS_DIFFERENT_FROM_REQUEST_ADDRESS (or whatever)
> 
> then you want an 'and'ing.

I'll take it as a given that you want 'and'ing in this example...
Negated conditions come into play here too. How about using a keyword
here too?

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

Absence of a logic keyword would imply 'OR', so unadorned sequences of
regexes would still be 'OR'ed.

-- 
 Dave Wolfe


Follow-Ups:
References:
Indexed By Date Previous: Re: Even more musings
From: Brock Rozen <brozen@webdreams.com>
Next: Re: Even more musings
From: Dave Wolfe <dwolfe@risc.sps.mot.com>
Indexed By Thread Previous: Re: More musings on a general access restriction mechanism
From: Jason L Tibbitts III <tibbs@hpc.uh.edu>
Next: Re: More musings on a general access restriction mechanism
From: Jason L Tibbitts III <tibbs@hpc.uh.edu>

Google
 
Search Internet Search www.greatcircle.com