[Otpasswd-talk] Re: Today's Hand Grenades

[Tomasz bla Fortuna]

Dnia Fri, 8 Jan 2010 16:23:32 -0600
Hannes Beinert <address@hidden> napisał(a):

> 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.
> 

Yeah, it would be good to clean it up a bit. I'd have to redesign it a
bit, parse argument (words you are proposing + db values) in one place
to some enum and then parse the variable itself. After config is
designed nicely I think it won't be that hard to implement it. 

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

Sure it's possible. Just some right/left trimming after split, as right
trimming I've already done I guess this won't hurt.

Problem is only not to make any mistake while parsing it. It's almost
the only part of program which is run without dropping permissions.

This part for sure not for now. But I believe cleaning up config file
before release is needed.
 
> 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.  
There's also question what is policy, and what is just a PAM module
configuration (like in the example of RETRY/RETRIES). ;)

> 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.
This is not technically needed, and can be told the user with
commentaries. This parsing really should be kept simple. ;) Still
prefixing variables is perfectly OK. They might be long though - user
doesn't need to neither remember them nor to type them.

I'm not very happy with POLICY/SPOLICY (long and doesn't really mean
much) but something in lines of this pair. 

Maybe ALLOW / ENFORCE? Allow being fully enforceable only in global
mode, while enforce being enforced mostly by PAM module? Not really
happy with this either. Think. ;)

In DB=user, there are:
1) Things user CAN overcome by editing file (e.g. skipping)
2) Things utility can deny him, but he will overcome utility by
changing state file. PAM will then deny him any authentication attempts
so this is enforced somehow.


> 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?

Renaming global to something is fine. I wasn't really happy about this
option either. I'm even not very sure about 'DB'. Maybe 'MODE' is
better?

Still we talk about two modes of operation; one grouping global, ldap
and mysql together.

> 
> 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.  :-)

Right... --skip currently works more like SETTING counter option, as it
gets the same arguments as -t and -l. So -s 3 doesn't skip by 3 but
sets counter to third passcard.

While I think it's not particularly bad it'd be nice to be able to say
something like -s '+3' or anything...

> 
> 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.

Cool!
 
> 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.

I'm pretty much busy before wednesday and a little bit more than usual
after it. You can do design of config if you like - the way you see it.
Keeping it mind that it's essential to be able to parse it easily
without mistakes. ;-)


-- 
Tomasz bla Fortuna
jid: bla(at)af.gliwice.pl
pgp: 0x90746E79 @ pgp.mit.edu
www: http://bla.thera.be

signature.asc
Description: PGP signature