On Fri, Jan 15, 2010 at 04:59, Tomasz bla Fortuna
<address@hidden> wrote:
2) Kind of update what make install does... questions:
a) Does it matter for Debian packaging what make install behaves like?
Especially how does it treats manual pages? Gentoo for instance does
compression on its own.
Debian will automagically compress your manpages, so there's no need to do so in make install.
b) Should we install documentation with make install? (Or prepare make
docs, OR leave it totally out and use distribution system for this task)
[...]
d) Do someone thinks we would be better off with autotools and would
like to do the switch? I've already got used to cmake a bit. ;) It
currently has testcases built in, which might make transition harder.
Doesn't matter for our purposes.
# Option USER defines a user, the utility will have to be run in certain
# conditions. This option is ignored when DB=user, and should be located
# after DB in config file.
# In situations when this option is not ignored, utility is
# SUID to either:
# root - (NI!) utility will drop it's privileges to USER as fast as it
# reads config file. This approach protects utility executable
# from being tampered by a successful attacker.
# USER - user which owns config file and /etc/otpasswd directory used
# to hold user database. This option is then used passively to
# make sure SUID is configured correctly.
USER=otpasswd
If the utility is SUID root, and it drops privlages to the otpasswd user, can't the otpasswd user modify the configuration file to change the "USER=" keyword to whoever?
Example:
App is started, it reads config file, drops to otpasswd, encounters malicious input or some other vulnerability, and arbitrary code is executed as the otpasswd user. The utility otpasswd user changes "USER" to "root" or "apache2" or some other user, and then the app is restarted by the attacker. The attacker exploits the same vulnerability and can now execute arbitrary code as the apache2 user.
# MySQL configuration (NI!)
I assume NI means "not implemented". Are you planning to include "not implemented" options in the 0.5 release?
# (Utility works on level 1, can be switched into 2 by -v option)
[...]
# 3 - Verbose: Errors, Warnings, Notices (-v option to utility)
Maybe I'm reading this wrong, but don't these seem to contradict each other? (level 3 vs level 2)
# Verbose mode is enabled by "debug" module option.
What's the difference between enabling it on the module or on the utility?
##
# 0 - OOB disabled
# 1 - OOB available on user request (by entering '.' on passcode prompt)
# 2 - OOB on request, requires static password prompt
# 3 - Sent OOB at the beginning of all authentication sessions.
##
PAM_OOB=0
Please make a note that OOB means "out of band" somewhere before using the abbr :)
# Utility Policy Configuration
#
# As oppossed to "System Policy" this works only if user doesn't
# have direct access to state database himself.
I'm confused: does this mean when using the .otpasswd file/folder in ~ or not?
If it does, then why is there a global policy? Can the user override it?