sts.pensive.org> <p04330106b77c2519ed1b@[192.168.1.7]>
<[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Thu,
Jul 19, 2001 at 12:06:09PM -0400
On Thu, Jul 19, 2001 at 12:06:09PM -0400, Forrest Aldrich wrote:
> I suggested the group thing previously, whereby if people were in a
> certain unix group, they could use leave-copy-on-server. Or
> vise-versa.
The trouble is, UNIX groups are not really designed to operate as a
general purpose database. If you've got to add users to a separate
group for each popper feature you might want to enable on a per-user
basis, you've got a different (but similar-sized) management headache
than creating one config file for each user; plus the code in popper is
going to get quite a bit more complicated enabling and disabling these
group checks for each feature that gets this capability added. And as
I've mentioned before, most UNIXes have a practical limit of how many
groups a user can be in, and some seem to have a limit of how many
users can be assigned to a given non-login group via /etc/group.
Putting an SQL interface for the configuration settings is a
reasonable solution for large sites, but might be hard to code
Here is an expanded version of a proposal I sent off-list and hadn't
copied to Randy yet; it also has some scaling problems, but probably
less so than the groups proposal. I had hoped to whip up some
prototype code, but I now doubt I will have time to work on it for
quite a while, so I'll just send the design idea.
...
I propose a generalised version of the present non-auth-file and
auth-file but extended to be usable for any current boolean config file
settings which are evaluated on a per-user basis.
The syntax for "true" and "false" in the config file would be
expanded to also provide as alternatives:
boolean = 'true' | 'false' | 'not' boolean | userspec
userspec = 'user_in' file-name-string
(If you really hate verbose syntax, substitute '<' for 'user_in' and
'!' for 'not'.)
When a user successfully authenticates, at that time (or after) the
userspec should be evaluated by reading the file as text, searching it
for the username, and will result in 'true' if the username is in the
file, 'false' if not.
This would allow one to place in a global configuration file commands
like:
set auto-delete = user_in "/usr/local/etc/qpopper/no-leave-mail"
or
set auto-delete = not user_in "/usr/local/etc/qpopper/leave-mail"
And you could use a similar setting for other parameters - pretty
much anything that currently is a "true/false" and is defined as
settable in the per-user configuration files. IMHO it looks easier to
solve a very general case like this, as opposed to adding more special
case parameters implemented via files, groups, et al.
One possible issue I see here is that inevitably somebody is going to
put 10,000 usernames into several of these files and then wonder why
they are taking a performance hit. This could be dealt with as a
documentation issue. Adding an SQL interface for the configuration
settings is a reasonable solution for large sites, but might be a bit
harder to code.
The general syntax above, though, is intended to allow for multiple types
of general user specifications eventually, if somebody wants to
implement them, e.g.:
'group_in' [group-string] to check group membership,
'user_sql' [sql_db] to query an SQL db for a setting, etc.
and then any time somebody implements a new type of user spec, they get
the freedom to use it for any type of parameter you like. Note that
currently asymmetric features like group-server-mode could easily be
implemented as general cases within this syntax as:
set server-mode = true
set server-mode = not group_in 'staff:shell'
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED]
WWJD? "JWRTFM!" - Scott Dorsey (kludge) "JWG" - Eddie Aikau
