Re: Please review wip/iodine

[Moritz Wilhelmy <ml+pkgsrc%wzff.de@localhost>]

Hi,

On Mon, Aug 06, 2012 at 20:26:12 -0400, Greg Troxel wrote:
> > iodine/iodined comes completely without a config file. Options are read
> > entirely through command line. Upstream told me my assumption about the
> > password being readable to anyone with access to ps(1) was wrong
> > (because apparently they overwrite the proctitle), so I assume there
> 
> That's probably os-dependent.

Indeed, it is.

> > isn't much in the way of just using them from within the rc script.
> > Including an rc-script would indeed simplify starting and restarting
> > iodine; I will supply one that reads a simple string of arguments from
> > rc.conf and applies them when starting iodine(d).
> >
> > Please complain if you have a better idea.
> 
> That sounds like exactly the right thing.   Really iodine should be able
> to not have command-line args and instead read /usr/pkg/etc/iodine.conf,
> including password, but that's not a great thing for pkgsrc to get into
> changing.   (I view iodine as not really different from aiccu.)
> 

Well, the obvious problem this brings is that the password is in
/etc/rc.conf in plain sight, if the password is supplied via command
line.

Just to clarify to everyone starting to read this thread just now, and
wondering what we're discussing:
The following options are available to read the password:

1. Environment: IODINE_PASS and IODINED_PASS
   (no idea why there have to be two variables, since you usually don't
   run the server and client on the same machine)

2. Commandline: -P parameter

3. Interactively, when prompted because 1 or 2 were not supplied

This *does* make sense for a program that does not include a config
file. Frankly, I don't even see the immediate need for one, especially
since the flags change depending on environment. iodine can probe some
of them, but if a DNS setup is hopefully borked, there might be manual
intervention required. Therefore, and because of the fact that rc.conf
is (and should be) readable to all users, I think it might be best to
not supply an rc.d script. But I really don't know.

On Mon, Aug 06, 2012 at 20:41:41 -0400, Matthew Mondor wrote:
> Indeed it wasn't, I assumed that it could read a configuration file,
> but I was also talking about an example config file for the DNS/domain
> etc.  But I only suggested possibilities, if you're the maintainer, you
> decide :)

Right, that's how I read it ;)
I just wanted to clarify that a config file does not exist.

> BSDs have setproctitle(3), I think that on Linux some custom argv or
> environment fiddling was necessary, I have no idea for other OSs.  But
> also, all of these have a race condition issue, that is, if a process
> actively lists processes it has a chance of getting the full command
> line before setproctitle(3) or equivalent is called.  Of course, we
> also have security.curtain (NetBSD specific sysctl)...  It would seem
> safer to me if it could instead read via stdin or from a config file.
> But I realize you're not the original developer, perhaps that we could
> simply warn about this in MESSAGE then?

Yep, I was aware of that. Putting it into MESSAGE is a good idea,
thanks. As far as I know, any means of setting the process title is
highly unportable. Also, even on NetBSD, security.curtain is not set by
default.


Best regards,

Moritz

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
pkgsrc-wip-review mailing list
pkgsrc-wip-review%lists.sourceforge.net@localhost
https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-review