otpasswd-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Otpasswd-talk] Today's Hand Grenades


From: Hannes Beinert
Subject: [Otpasswd-talk] Today's Hand Grenades
Date: Fri, 8 Jan 2010 16:23:32 -0600

1. I've been thinking about the otpasswd.conf file.  One of the things
that occurs to me is that it would be more user-friendly if instead of
numeric values, one could use string values such as ALLOW, PERMIT,
DISALLOW, NOALLOW, NOPERMIT, DENY, ENFORCE, OPTIONAL or whatever.  I
think this would make things more lucid, and it would also allow
someone to grep the config file to get a setting, and immediately be
able to understand the meaning of the setting.  As it is right now, if
I grep on SHOW_ALLOW, I almost need to go back to the config file to
see what that value setting means.

I realize there are other types of settings to which the above
keywords wouldn't be appropriate, but one could use a set of keywords
appropriate to each parameter key, such as RETRY = (DISALLOW | NEXT |
SAME).  Etc.

2. Any chance of allowing whitespace on either side of the equal sign
in the config?  ;-)

3. Generally speaking, would it make sense for all config parameters
to have a standard prefix to indicate that they can, or cannot be
enforced in DB=USER?  I'm not sure about this idea -- it just occurred
to me that something to make the parameters more self-documenting.  A
prefix like "POLICY_RETRY" or "POLICY_RETRIES" for policies that are
always enforced.  Then "SYSPOL" or "SPOLICY" for policies that can
only be enforced in DB=GLOBAL -- like "SPOLICY_ALLOW_KEY_GENERATION".
An alternative approach which would complicate the structure of the
config file (and therefore is probably less than optimal) would be to
use "sections".  Ie, something like "[GLOBAL DB]" for parameters that
make sense only in GLOBAL DB mode, and perhaps [POLICY] for those that
are always enforced.  And [GENERAL] for settings that aren't policy
related.

4. You know, I've been struggling with a way to talk about "DB=USER"
and "DB=GLOBAL" -- since those "terms" are conceptually accurate, but
they don't roll off the tongue very easily.  There's always "Global DB
mode" and "User DB mode", but that is only slightly better.  One
confusion is that "DB=GLOBAL" (or "Global DB mode") doesn't obviously
*seem* to apply to "DB=LDAP" or "DB=MYSQL".  One thought I had was to
call these two operational modes "User mode" and "System mode".  It
really would be nice to have something that's a little easier to talk
about in the manuals...  I don't know, though.  Thoughts?

5. You knew I was going to ask about this, right?  What do you have in
mind with the ALLOW_BACKWARD_SKIPPING?  That seems...
counter-intuitive.  :-)

6. In the ChangeLog you have an item asking whether OTPasswd will be
PPPv3 compatible on a big-endian system.  I think that will "come out
in the wash" when we try to test OTPasswd on a PPC Mac.  As it
happens, I have one sitting here.  ;-)  Just FYI.

By the way, I realize you've got less free time right now to devote to
this project.  If you think any of these ideas are worth anything, I'd
be happy to do some of the coding, if that would help.

Hannes.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]