Hi, Dale :-)
On Fri, 7 Mar 2003, Dale Woolridge wrote:
>On 7-Mar-2003 08:00 Andreas Aardal Hanssen wrote:
>| I am willing to consider another approach if you can point me to
>| information about why it's a bad idea. I searched on google groups a bit
>| and all I found was people that recommended this behavior over other
>| solutions. :/
> There are still systems that allow anyone to look at the
> environment of another process (e.g., ps -e). Newer versions
> of linux 2.[24]/freebsd/others protect against this, but it's
> still considered a bad idea. I would recommend using a pipe/fd
> instead.
I choose to cave in here. I dug deeply into the depths of
groups.google.com and found that several places there were complaints
about the security implications. What confused me at first was that so
many actually suggested using the environment for passing this kind of
info.
It seems that the principle is that as long as there is no requirement in
any standard saying that the environment should be secure and readable
only for the said process, we can not use this for passing auth info in
plain text.
I have one approach that I request your feedback on: the authenticator
reads the username and password from stdin in netstring format, for
example:
+4,8:andy->password
For me this seems to be almost as simple as using the environment from a
technical standpoint. We could also use checkpassword's format, but I
think some people will struggle with getting the fd 3 stuff to work. I
want this to be really simple.
We might even want to throw up a sample parser for perl and C.
Do we have other suggestions to formats for passing the password and
username to Binc's authenticator?
>| This is in practise what the uidpwd program is meant to do. :-)
>| The authenticator can change to new directories as much as is needed,
>| because in the end it's bincimapd that changes (and/or chroots) to the
>| Maildir.
> Right, except that bincimapd is expecting a path that it can chroot()
> to (after it appends 'Mailbox { path }'). I suppose I was making
> a distinction between the uidpwd dir, which is typically the home of
> the auth'd user, and the maildir. These coincide for system users
> for Mailbox { path = ""; }, but this isn't necessarily so for virtual
> users.
I agree. I'm trying to figure out a good way to make this all work.
> In the case of checkvpw, the restrictions make sense when you only
> have a single mailbox (like with POP3) or all your folders exist
> as subdirectories of your Maildir (=INBOX) as with Maildir++.
> With a more open folder structure, the cwd is likely just the best
> location where the (system) user has write privileges and the
> maildir is the default (INBOX) mail folder for (virtual) users.
This makes sense.
Andy
--
Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg
Author of Binc IMAP | Nil desperandum
