[Otpasswd-talk] Re: Otpasswd tasks

[Tomasz bla Fortuna]

Dnia Sun, 27 Dec 2009 14:11:13 -0600
Hannes Beinert <address@hidden> napisał(a):

> Hello Tomasz,
> 
> I've been watching otpasswd develop before my eyes, and I was
> wondering if there is anything I can do to help?  The code has been
> changing so quickly, that I really can't say I've been keeping up,
> however I could perhaps see what I could do about test cases, or
> writing/editing documentation, or whatever.
> 
> One other thing I could offer some help with is perhaps packaging.
> I'm no expert, but I've done some.  Also, I have a Mac that I could
> use to develop an OSX package with.  Alternatively, I could give you
> access to the Mac, too.
> 
> Hannes.
Hi,

Thanks for this proposition. There're some things which can be done
independently of the code, sure:

1) Testing. Needed ;-) But it would be better to wait until this
global db works and I implement parts of policy... I'll create some tag
briefly.

And normal testing (using it) is fine, and you can thing about some
testcases which can also be used (code coverage might help). e.g. OOB is
not tested at all currently...

2) Portability/Packaging. I'd like to run it on Linux, BSD and Mac
minimally. Should work on Solaris also without big pain. This might
require some header changes, maybe some #ifs and cmake changes.

My fast check on FreeBSD made me change PAM-headers-include a bit, so
it'd be cool if you can try to compile it on Mac and see if headers are
ok, and if cmake does it's job. If it compiles then just wait for the
next tagged version and it can be packaged. ;-)

I've had one mail from guy who was compiling it on debian with some
cmake problems; I guess it can be enhanced somehow. I've got no idea how
to make .deb packages and how difficult it is to place project inside
experimental debian branch. It would be cool to do so as it'd make the
project better reviewed.


3) Documentation. Hm. It would be cool to create a manual page, at
least one single for utility out of --help screen with some initial
paragraphs from README. I guess this can be done easily by taking
something ready and just remaking it. Checking if README is
gramatically correct would be cool too. ;-)



BTW.
I wonder about default configuration. It could look like this:
otpasswd user created by package.
/etc/otpasswd owned by otpasswd user.
/etc/otpasswd/otpasswd.conf is a config, owned by otpasswd user.
/etc/otpasswd/otshadow  - empty, otpasswd-owned, rw- --- ---
/etc/pam.d/otpasswd-login owned by root
/usr/bin/otpasswd is not SUID, but is owned by otpasswd.
State is kept in user homes.

Then if user wants to use global DB he can easily make binary SUID and
change config to use DB=global... 

OTOH if he changes DB=ldap then he must change (or otpasswd can do it
automatically) config to be rw- --- --- as it will hold password...

OR
Make otpasswd SUID by default, then config can by default
read-only-by-owner. As it reads DB=user it can drop this permissions
fast. Switching to other db is faster (And safer) then. 


Just think about it in free time.

Another problem: otpasswd with db=ldap can either use master password
for everything or ask user to supply password for his part of LDAP
database (then no suid is again required; but PAM will need password
stored separately from config in only-root-readable file). 



I'd like to decide on default configuration fast so it won't get
more complicated then it is already. ;-) I've already dropped SGID idea
and this will make it easier to write.


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

signature.asc
Description: PGP signature