postfixadmin-devel

[Postfixadmin-devel] config.local.php not being read.

[<me...@td...>]

Hi,

I did an svn co on trunk today (rev 626). I have a config.local.php that is
not being read when I try to run setup.php. When I try to run setup.php, I
get the following warning:
Please edit config.inc.php - change $CONF['configured'] to true after
setting your database settings

If I modify config.inc.php as instructed above then the warning goes away
but my database config does not get read since the settings for it are in
config.local.php. I have another test system with svn rev 564 installed
using the same config.local.php except for some machine specific changes and
it works as advertised.

Can someone give me an idea how to troubleshoot this problem? A diff of
config.inc.php between the 2 systems shows nothing significant. The
following is what I have in config.local.php:

<?php
$CONF['configured'] = true;

$CONF['postfix_admin_url'] = 'http://foggy.tntechs.com/pfa';

$CONF['database_type'] = 'mysqli';
$CONF['database_host'] = 'localhost';
$CONF['database_user'] = 'mydb_user';
$CONF['database_password'] = 'my_passwd';
$CONF['database_name'] = 'postfix';
$CONF['database_prefix'] = '';

$CONF['encrypt'] = 'system';

$CONF['alias_control'] = 'YES';
$CONF['alias_control_admin'] = 'YES';

$CONF['create_mailbox_subdirs_prefix']='';

Regards,

-- 
Tom			me...@td...		Spamtrap address	 		me...@td...

Re: [Postfixadmin-devel] config.local.php not being read.

[<me...@td...>]

Hi,

Sorry to followup to my own post but I have more info to add. Please see below.

On Sat, 11 Apr 2009, me...@td... wrote:

> Hi,
>
> I did an svn co on trunk today (rev 626). I have a config.local.php that is
> not being read when I try to run setup.php. When I try to run setup.php, I
> get the following warning:
> Please edit config.inc.php - change $CONF['configured'] to true after
> setting your database settings
>
> If I modify config.inc.php as instructed above then the warning goes away
> but my database config does not get read since the settings for it are in
> config.local.php. I have another test system with svn rev 564 installed
> using the same config.local.php except for some machine specific changes and
> it works as advertised.
>
> Can someone give me an idea how to troubleshoot this problem? A diff of
> config.inc.php between the 2 systems shows nothing significant. The
> following is what I have in config.local.php:
>
> <?php
> $CONF['configured'] = true;
>
> $CONF['postfix_admin_url'] = 'http://foggy.tntechs.com/pfa';
>
> $CONF['database_type'] = 'mysqli';
> $CONF['database_host'] = 'localhost';
> $CONF['database_user'] = 'mydb_user';
> $CONF['database_password'] = 'my_passwd';
> $CONF['database_name'] = 'postfix';
> $CONF['database_prefix'] = '';
>
> $CONF['encrypt'] = 'system';
>
> $CONF['alias_control'] = 'YES';
> $CONF['alias_control_admin'] = 'YES';
>
> $CONF['create_mailbox_subdirs_prefix']='';

In config.inc.php we have he following statement:
/*****************************************************************
  *  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  * The following line needs commenting out or removing before the
  * application will run!
  * Doing this implies you have changed this file as required.
  * i.e. configuring database etc; specifying setup.php password etc.
$CONF['configured'] = false;
  */

If as it says above I simply comment out the configured statement
and make all of my local changes to config.local.php, I am then able to
run setup.php successfully and add my superuser account. The problem
is that I still cannot login to pfa. I never get the login screen, I keep
getting the "Welcome to Postfix Admin" screen. If I change the 
$CONF['configured'] = false; to $CONF['configured'] = true; and uncomment
it, then I get a login screen and I am able to login successfully.

This is a new install on a test box. No upgrades involved.

Is this a bug or a feature? :-) If it is a bug should I file a bug report
somewhere?

Regards,

-- 
Tom			me...@td...		Spamtrap address	 		me...@td...

Re: [Postfixadmin-devel] config.local.php not being read.

[David G. <da...@co...>]

me...@td... wrote :
> Hi,
> 
> Sorry to followup to my own post but I have more info to add. Please see below.
> 
> On Sat, 11 Apr 2009, me...@td... wrote:
> 
> > Hi,
> >
> > I did an svn co on trunk today (rev 626). I have a config.local.php that is
> > not being read when I try to run setup.php. When I try to run setup.php, I
> > get the following warning:
> > Please edit config.inc.php - change $CONF['configured'] to true after
> > setting your database settings
> >
> > If I modify config.inc.php as instructed above then the warning goes away
> > but my database config does not get read since the settings for it are in
> > config.local.php. I have another test system with svn rev 564 installed
> > using the same config.local.php except for some machine specific changes and
> > it works as advertised.
> >
> > Can someone give me an idea how to troubleshoot this problem? A diff of
> > config.inc.php between the 2 systems shows nothing significant. The
> > following is what I have in config.local.php:
> >
> > <?php
> > $CONF['configured'] = true;
> >
> > $CONF['postfix_admin_url'] = 'http://foggy.tntechs.com/pfa';
> >
> > $CONF['database_type'] = 'mysqli';
> > $CONF['database_host'] = 'localhost';
> > $CONF['database_user'] = 'mydb_user';
> > $CONF['database_password'] = 'my_passwd';
> > $CONF['database_name'] = 'postfix';
> > $CONF['database_prefix'] = '';
> >
> > $CONF['encrypt'] = 'system';
> >
> > $CONF['alias_control'] = 'YES';
> > $CONF['alias_control_admin'] = 'YES';
> >
> > $CONF['create_mailbox_subdirs_prefix']='';
> 
> In config.inc.php we have he following statement:
> /*****************************************************************
>   *  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>   * The following line needs commenting out or removing before the
>   * application will run!
>   * Doing this implies you have changed this file as required.
>   * i.e. configuring database etc; specifying setup.php password etc.
> $CONF['configured'] = false;
>   */
> 
> If as it says above I simply comment out the configured statement
> and make all of my local changes to config.local.php, I am then able to
> run setup.php successfully and add my superuser account. The problem
> is that I still cannot login to pfa. I never get the login screen, I keep
> getting the "Welcome to Postfix Admin" screen. If I change the 
> $CONF['configured'] = false; to $CONF['configured'] = true; and uncomment
> it, then I get a login screen and I am able to login successfully.
> 
> This is a new install on a test box. No upgrades involved.
> 
> Is this a bug or a feature? :-) If it is a bug should I file a bug report
> somewhere?
> 


I'd guess that config.local.php isn't being read in, to overwrite
anything in config.inc.php

I wasn't aware of config.local.php - this is a new thing to me

thanks
David.


-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] config.local.php not being read.

[<me...@td...>]

On Sun, 12 Apr 2009, David Goodwin wrote:

> me...@td... wrote :
>> Hi,
>>
>> Sorry to followup to my own post but I have more info to add. Please see below.
>>
>> On Sat, 11 Apr 2009, me...@td... wrote:
>>
>>> Hi,
>>>
>>> I did an svn co on trunk today (rev 626). I have a config.local.php that is
>>> not being read when I try to run setup.php. When I try to run setup.php, I
>>> get the following warning:
>>> Please edit config.inc.php - change $CONF['configured'] to true after
>>> setting your database settings
>>>
>>> If I modify config.inc.php as instructed above then the warning goes away
>>> but my database config does not get read since the settings for it are in
>>> config.local.php. I have another test system with svn rev 564 installed
>>> using the same config.local.php except for some machine specific changes and
>>> it works as advertised.
>>>
>>> Can someone give me an idea how to troubleshoot this problem? A diff of
>>> config.inc.php between the 2 systems shows nothing significant. The
>>> following is what I have in config.local.php:
>>>
>>> <?php
>>> $CONF['configured'] = true;
>>>
>>> $CONF['postfix_admin_url'] = 'http://foggy.tntechs.com/pfa';
>>>
>>> $CONF['database_type'] = 'mysqli';
>>> $CONF['database_host'] = 'localhost';
>>> $CONF['database_user'] = 'mydb_user';
>>> $CONF['database_password'] = 'my_passwd';
>>> $CONF['database_name'] = 'postfix';
>>> $CONF['database_prefix'] = '';
>>>
>>> $CONF['encrypt'] = 'system';
>>>
>>> $CONF['alias_control'] = 'YES';
>>> $CONF['alias_control_admin'] = 'YES';
>>>
>>> $CONF['create_mailbox_subdirs_prefix']='';
>>
>> In config.inc.php we have he following statement:
>> /*****************************************************************
>>   *  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>   * The following line needs commenting out or removing before the
>>   * application will run!
>>   * Doing this implies you have changed this file as required.
>>   * i.e. configuring database etc; specifying setup.php password etc.
>> $CONF['configured'] = false;
>>   */
>>
>> If as it says above I simply comment out the configured statement
>> and make all of my local changes to config.local.php, I am then able to
>> run setup.php successfully and add my superuser account. The problem
>> is that I still cannot login to pfa. I never get the login screen, I keep
>> getting the "Welcome to Postfix Admin" screen. If I change the
>> $CONF['configured'] = false; to $CONF['configured'] = true; and uncomment
>> it, then I get a login screen and I am able to login successfully.
>>
>> This is a new install on a test box. No upgrades involved.
>>
>> Is this a bug or a feature? :-) If it is a bug should I file a bug report
>> somewhere?
>>
>
>
> I'd guess that config.local.php isn't being read in, to overwrite
> anything in config.inc.php
>
> I wasn't aware of config.local.php - this is a new thing to me

I was just going by the comments at the bottom of config.inc.php which say:

// If you want to keep most settings at default values and/or want to ensure
// that future updates work without problems, you can use a separate config
// file (config.local.php) instead of editing this file and override some
// settings there.
if (file_exists(dirname(__FILE__) . '/config.local.php')) { # for /
     include(dirname(__FILE__) . '/config.local.php');

So should I assume this will not work, is this something that is likely to
be fixed or am I asking the wrong person? I like the idea of not having
my config file overwritten during upgrades but it is not the end of the
earth either.

Thanks for the response.

Regards,

-- 
Tom			me...@td...		Spamtrap address	 		me...@td...

Re: [Postfixadmin-devel] config.local.php not being read.

[Christian B. <pos...@cb...>]

Hello,

Am Sonntag, 12. April 2009 schrieb me...@td...:
> On Sun, 12 Apr 2009, David Goodwin wrote:
> > me...@td... wrote :
> >> On Sat, 11 Apr 2009, me...@td... wrote:
> >>> The following is what I have in config.local.php:
> >>>
> >>> <?php
> >>> $CONF['configured'] = true;
...
> > I wasn't aware of config.local.php - this is a new thing to me

Oh, it's quite old ;-)

svn annotate says:
   151 christian_boltz // If you want to keep most settings at default values and/or want to ensure
   151 christian_boltz // that future updates work without problems, you can use a separate config
   151 christian_boltz // file (config.local.php) instead of editing this file and override some
   151 christian_boltz // settings there.
   251  GingerDog      if (file_exists(dirname(__FILE__) . '/config.local.php')) { # for /
   251  GingerDog          include(dirname(__FILE__) . '/config.local.php');
   251  GingerDog      }

The basic idea was from me (r151, 2007-10-12), and you (GingerDog) then 
made the better inclusion code in r251 (2007-12-02) ;-)

> So should I assume this will not work, is this something that is
> likely to be fixed or am I asking the wrong person? I like the idea
> of not having my config file overwritten during upgrades but it is
> not the end of the earth either.

Using config.local.php works for me without problems.

If you are unsure if config.local.php is read on your system, add something like
    die ("reading config.local.php works");
to config.local.php ;-)

After testing with your config.local.php, I'm quite sure it misses a 
setting.
You have to add a setup password: (that's quite new! - r616)
    $CONF['setup_password'] = "topsecret";

After this change (and changing the database secrets to match my 
installation), I can login.

If it still doesn't work, check if you have a typo in the filename ;-)


Regards,

Christian Boltz
-- 
Ich freue mich auf das Eröffnungsspiel Deutschland gegen Costa Rica.
Auf der einen Seite eine Bananenrepublik und auf der anderen Seite:
Costa Rica.   [Thomas Gottschalk, Wetten dass...?, 10.12.2005]

Re: [Postfixadmin-devel] config.local.php not being read.

[<me...@td...>]

On Sun, 12 Apr 2009, Christian Boltz wrote:

> Hello,
>
> Am Sonntag, 12. April 2009 schrieb me...@td...:
>> On Sun, 12 Apr 2009, David Goodwin wrote:
>>> me...@td... wrote :
>>>> On Sat, 11 Apr 2009, me...@td... wrote:
>>>>> The following is what I have in config.local.php:
>>>>>
>>>>> <?php
>>>>> $CONF['configured'] = true;
> ...
>>> I wasn't aware of config.local.php - this is a new thing to me
>
> Oh, it's quite old ;-)
>
> svn annotate says:
>   151 christian_boltz // If you want to keep most settings at default values and/or want to ensure
>   151 christian_boltz // that future updates work without problems, you can use a separate config
>   151 christian_boltz // file (config.local.php) instead of editing this file and override some
>   151 christian_boltz // settings there.
>   251  GingerDog      if (file_exists(dirname(__FILE__) . '/config.local.php')) { # for /
>   251  GingerDog          include(dirname(__FILE__) . '/config.local.php');
>   251  GingerDog      }
>
> The basic idea was from me (r151, 2007-10-12), and you (GingerDog) then
> made the better inclusion code in r251 (2007-12-02) ;-)
>
>> So should I assume this will not work, is this something that is
>> likely to be fixed or am I asking the wrong person? I like the idea
>> of not having my config file overwritten during upgrades but it is
>> not the end of the earth either.
>
> Using config.local.php works for me without problems.
>
> If you are unsure if config.local.php is read on your system, add something like
>    die ("reading config.local.php works");
> to config.local.php ;-)
>
> After testing with your config.local.php, I'm quite sure it misses a
> setting.
> You have to add a setup password: (that's quite new! - r616)
>    $CONF['setup_password'] = "topsecret";

That was it. I missed the setup_password parameter but set it in
config.inc.local when I needed to add the superuser. It never occurred to me
that not having that parameter set would keep config.local.php from working.

Am I missing how this config.inc.php vs config.inc.local works?

I was thinking that the values set in config.inc.local will over write values
set in config.inc.php but if a value parameter does not exist in 
config.local.php then the value in config.inc.php will be in effect. This would
appear to be wrong since the default config.inc.php was set to
$CONF['setup_password'] = 'changeme';

So my question is does config.inc.php get read at all if config.local.php exists?
It would appear not but I just want to be sure.

If my suspicions are correct then might I suggest indicating that in the
comments to avoid others getting confused.

Thanks for the help.

Regards,

-- 
Tom			me...@td...		Spamtrap address	 		me...@td...

Re: [Postfixadmin-devel] config.local.php not being read.

[Christian B. <pos...@cb...>]

Hello,

Am Montag, 13. April 2009 schrieb me...@td...:
> On Sun, 12 Apr 2009, Christian Boltz wrote:
> > You have to add a setup password: (that's quite new! - r616)
> >    $CONF['setup_password'] = "topsecret";
>
> That was it. I missed the setup_password parameter but set it in
> config.inc.local when I needed to add the superuser. It never
> occurred to me that not having that parameter set would keep
> config.local.php from working.

Not having the setup_password set will keep postfixadmin from working at 
all.

@GingerDog: 
- What about checking setup_password only in setup.php?
- What about storing the password md5-hashed? That makes it harder for 
  the admin to set it up, but is more secure if someone manages to read 
  config.inc.php...

> I was thinking that the values set in config.inc.local will over
> write values set in config.inc.php 

Typo? The first filename should be ...local.php ;-)

> but if a value parameter does not 
> exist in config.local.php then the value in config.inc.php will be in
> effect. 

Correct.

> This would appear to be wrong since the default 
> config.inc.php was set to $CONF['setup_password'] = 'changeme';

We have a special check if the setup_password is "changeme" ;-)

    if($CONF['setup_password'] == 'changeme') {
        die("You must specify a password in config.inc.php
             (\$CONF['setup_password']) in order to access setup.php");
    }

(see also .sig below *g*)

> So my question is does config.inc.php get read at all if
> config.local.php exists? It would appear not but I just want to be
> sure.

First config.inc.php is read, then config.local.php.

This means that settings in config.local.php will overwrite settings 
from config.inc.php.


Regards,

Christian Boltz
-- 
looks like you have some special code in yast for password "x", maybe I
should use the even more secure new password "y" in the future  ?! ;-)
[Harald Koenig in https://bugzilla.novell.com/show_bug.cgi?id=148464]

Re: [Postfixadmin-devel] config.local.php not being read.

[<me...@td...>]

On Mon, 13 Apr 2009, Christian Boltz wrote:

> Hello,
>
> Am Montag, 13. April 2009 schrieb me...@td...:
>> On Sun, 12 Apr 2009, Christian Boltz wrote:
>>> You have to add a setup password: (that's quite new! - r616)
>>>    $CONF['setup_password'] = "topsecret";
>>
>> That was it. I missed the setup_password parameter but set it in
>> config.inc.local when I needed to add the superuser. It never
>> occurred to me that not having that parameter set would keep
>> config.local.php from working.
>
> Not having the setup_password set will keep postfixadmin from working at
> all.
>
> @GingerDog:
> - What about checking setup_password only in setup.php?
> - What about storing the password md5-hashed? That makes it harder for
>  the admin to set it up, but is more secure if someone manages to read
>  config.inc.php...
>
>> I was thinking that the values set in config.inc.local will over
>> write values set in config.inc.php
>
> Typo? The first filename should be ...local.php ;-)

Yes!! Sorry. :-(

>
>> but if a value parameter does not
>> exist in config.local.php then the value in config.inc.php will be in
>> effect.
>
> Correct.
>
>> This would appear to be wrong since the default
>> config.inc.php was set to $CONF['setup_password'] = 'changeme';
>
> We have a special check if the setup_password is "changeme" ;-)
>
>    if($CONF['setup_password'] == 'changeme') {
>        die("You must specify a password in config.inc.php
>             (\$CONF['setup_password']) in order to access setup.php");
>    }

Hummm, interesting. I did not get that error the first. Wonder what
I did wrong. Oh well it is now working as advertised.

>
> (see also .sig below *g*)

:-)

>
>> So my question is does config.inc.php get read at all if
>> config.local.php exists? It would appear not but I just want to be
>> sure.
>
> First config.inc.php is read, then config.local.php.
>
> This means that settings in config.local.php will overwrite settings
> from config.inc.php.

Thanks., I think I got it now. :-)

Regards,

-- 
Tom			me...@td...		Spamtrap address	 		me...@td...

Re: [Postfixadmin-devel] config.local.php not being read.

[David G. <da...@co...>]

> @GingerDog: 
> - What about checking setup_password only in setup.php?


We could do.

> - What about storing the password md5-hashed? That makes it harder for 
>   the admin to set it up, but is more secure if someone manages to read 
>   config.inc.php...
> 

Hmm... it's a pain for administrators to create a md5-hashed password
on the command line - isn't it? If they can read hte file, then they
can read/write to the database....  so there would be bigger things to
worry about.

Re: [Postfixadmin-devel] config.local.php not being read.

[Christian B. <pos...@cb...>]

Hello,

Am Montag, 13. April 2009 schrieb David Goodwin:
> > - What about checking setup_password only in setup.php?
>
> We could do.
>
> > - What about storing the password md5-hashed? That makes it harder
> > for the admin to set it up, but is more secure if someone manages
> > to read config.inc.php...
>
> Hmm... it's a pain for administrators to create a md5-hashed password
> on the command line - isn't it? 

More or less ;-)

We could do it in setup.php like in the Typo3 install tool:

    "Wrong password! The password you entered has md5 hash ......"

> If they can read hte file, then they can read/write to the 
> database....  so there would be bigger things to worry about. 

If an attacker can read config.inc.php (let's say by some vulnerable 
other PHP scripts), there's still a difference:

a) using setup.php with the setup password is easy - just type it.
b) using the database password requires access to phpMyAdmin etc.
   which makes it at least slightly harder.

We could also get rid of the code checking for "changeme" or empty setup 
password - md5(something) will never return "changeme" ;-) and the user 
will simply run into the "wrong setup password" message.

Final note: If we want to use md5 for the setup password, we should 
switch _now_ so that less users are affected.


Regards,

Christian Boltz
-- 
> Hilft vielleicht noch etwas anderes?
Eine genaue Fehlerbeschreibung. (Glaskugel oder Karten versagen bei 
technischen Problemen immer, daher packe ich die auch nicht aus).
[Helga Fischer in suse-linux]

Re: [Postfixadmin-devel] config.local.php not being read.

[<tan...@li...>]

On 4/13/2009 3:14 PM, Christian Boltz wrote:
> Final note: If we want to use md5 for the setup password, we should 
> switch _now_ so that less users are affected.

I thought this would be optional... ? You're saying everyone would be
FORCED to do so?

-- 

Best regards,

Charles

Re: [Postfixadmin-devel] config.local.php not being read.

[David G. <da...@co...>]

> 
> We could do it in setup.php like in the Typo3 install tool:
> 
>     "Wrong password! The password you entered has md5 hash ......"
> 
> > If they can read hte file, then they can read/write to the 
> > database....  so there would be bigger things to worry about. 
> 
> If an attacker can read config.inc.php (let's say by some vulnerable 
> other PHP scripts), there's still a difference:
> 
> a) using setup.php with the setup password is easy - just type it.
> b) using the database password requires access to phpMyAdmin etc.
>    which makes it at least slightly harder.
> 

OK. Change to use md5/sha1/whatever (perhaps embed sha1: at the start
of the string??)


> 
> Final note: If we want to use md5 for the setup password, we should 
> switch _now_ so that less users are affected.

OK. Well volunteered :)

David.

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] config.local.php not being read.

[David G. <da...@co...>]

tan...@li... wrote :
> On 4/13/2009 3:14 PM, Christian Boltz wrote:
> > Final note: If we want to use md5 for the setup password, we should 
> > switch _now_ so that less users are affected.
> 
> I thought this would be optional... ? You're saying everyone would be
> FORCED to do so?
> 

Yes. The setup_password is a mandatory step now. Failing to do it
leaves a big security hole open when ever a user upgrades (especially
if it's automatic via e.g. apt)

David.

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] config.local.php not being read.

[<tan...@li...>]

On 4/13/2009 4:49 PM, David Goodwin wrote:
>>> Final note: If we want to use md5 for the setup password, we should 
>>> switch _now_ so that less users are affected.

>> I thought this would be optional... ? You're saying everyone would be
>> FORCED to do so?

> Yes. The setup_password is a mandatory step now. Failing to do it
> leaves a big security hole open when ever a user upgrades (especially
> if it's automatic via e.g. apt)

Oh... wait... is this just for the admin password? Or for all email
account passwords?

Re: [Postfixadmin-devel] config.local.php not being read.

[David G. <da...@co...>]

tan...@li... wrote :
> On 4/13/2009 4:49 PM, David Goodwin wrote:
> >>> Final note: If we want to use md5 for the setup password, we should 
> >>> switch _now_ so that less users are affected.
> 
> >> I thought this would be optional... ? You're saying everyone would be
> >> FORCED to do so?
> 
> > Yes. The setup_password is a mandatory step now. Failing to do it
> > leaves a big security hole open when ever a user upgrades (especially
> > if it's automatic via e.g. apt)
> 
> Oh... wait... is this just for the admin password? Or for all email
> account passwords?

The passowrd which allows you to run the setup.php page (and create
new admin users)

David.

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] config.local.php not being read.

[Christian B. <pos...@cb...>]

Hello,

Am Montag, 13. April 2009 schrieb tan...@li...:
> Oh... wait... is this just for the admin password? Or for all email
> account passwords?

The $CONF['setup_password'] is the super-super-admin ;-) password needed 
to create new super-admins via setup.php. This is what I want to store 
in a hashed format (md5, sha1).

This change won't affect the passwords you have in your database for 
(super-)admins and mailboxes.

To make the story short: You'll (only) have to edit 
$CONF['setup_password'].


Regards,

Christian Boltz
-- 
Nicht das ich frei von Paranoia Schueben waere ;), aber wenn Dir das
passiert spiel sofort Lotto, bei dem Glueck bekommst Du bestimmt 4
Wochen den 6er mit Superzahl.   [Maik Holtkamp in suse-linux]

Re: [Postfixadmin-devel] config.local.php not being read.

[David G. <da...@co...>]

> OK. Change to use md5/sha1/whatever (perhaps embed sha1: at the start
> of the string??)
> 

Having a reasonable salt might be a good idea too - even if it is just
something stupid like 'postfixadmin'

David.


-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] config.local.php not being read.

[<tan...@li...>]

On 4/13/2009 5:39 PM, Christian Boltz wrote:
> The $CONF['setup_password'] is the super-super-admin ;-) password needed 
> to create new super-admins via setup.php. This is what I want to store 
> in a hashed format (md5, sha1).

Oh, right... should have seen that... sorry... :)

> This change won't affect the passwords you have in your database for 
> (super-)admins and mailboxes.
> 
> To make the story short: You'll (only) have to edit 
> $CONF['setup_password'].

Right... thanks, and sorry for the noise...

See what I get for unleashing my fingers on a dev mail list? ;)

Re: [Postfixadmin-devel] config.local.php not being read.

[Christian B. <pos...@cb...>]

Hello,

Am Dienstag, 14. April 2009 schrieb tan...@li...:
> See what I get for unleashing my fingers on a dev mail list? ;)

You get answers, nothing else ;-)

And I'm glad you have a look at what we are doing and point out possible 
problems before they can hit someone. Even if the problem is "just" an 
unclear mail, it's better to ask.


Regards,

Christian Boltz
-- 
"Microsoft spel chekar worgs grate!"

Re: [Postfixadmin-devel] config.local.php not being read.

[Christian B. <pos...@cb...>]

Hello,

Am Dienstag, 14. April 2009 schrieb David Goodwin:
> > OK. Change to use md5/sha1/whatever (perhaps embed sha1: at the
> > start of the string??)
>
> Having a reasonable salt might be a good idea too - even if it is
> just something stupid like 'postfixadmin'

Indeed, using a salt is always a good idea. However, I don't like the 
static value.

I just commited a modified version of setup.php (r629) which uses hashed 
and salted passwords (sorry, no pepper ;-)

The salt is a md5-hash computed from the remote IP, the time and a 
random value. This might not be cyrptically perfect, but I doubt there 
will be two postfixadmin installations using the same salt ;-)
(Of course, when checking against the password in config.inc.php, the 
salt is read from $CONF.)

The salt and the password are then hashed with sha1.

If someone enters a wrong setup password, he will get the hash of 
his/her password displayed copy&paste ready for inclusion in 
config.inc.php.


Please proofread my code - this is highly security relevant, therefore 
another pair of eyes are a good idea. Also test setup.php with valid 
and invalid setup passwords.

Note: I'll remove the check for $CONF['setup_password'] from common.php 
again because:
- it's no longer really needed - no hashed password will result in 
  something simple like "changeme" or an empty string
- checking the setup_password in setup.php (the only place where it is 
  used) is enough
- blocking the whole postfixadmin just because the setup password has 
  not been set (= current behaviour) will cause lots of needless 
  problems if someone upgrades from a previous version.
- The admin _will_ setup a password for sure as soon as he needs to 
  create a super-admin via setup.php ;-)
- (if I missed an argument why to keep the check in common.php, please 
  speak up!)

I also think that we no longer need to use the "developer hack"
    $CONF['configured'] = 'I_know_the_risk_of_not_deleting_setup.php'
and should remove the code sections checking for it (index.php, 
login.php).


Regards,

Christian Boltz
-- 
>und was ist "Winter"?
Ein Zeitraum, in dem von der Decke des grossen blauen Raum gelegentlich
groessere oder kleinere Mengen kalten weissen Drecks fallen, der aus
kristallinem Dihydrogenmonoxid besteht.        [Alexander Schreiber]

Re: [Postfixadmin-devel] config.local.php not being read.

[David G. <da...@co...>]

Christian Boltz wrote :
> Hello,
> 
> Am Dienstag, 14. April 2009 schrieb David Goodwin:
> > > OK. Change to use md5/sha1/whatever (perhaps embed sha1: at the
> > > start of the string??)
> >
> > Having a reasonable salt might be a good idea too - even if it is
> > just something stupid like 'postfixadmin'
> 
> Indeed, using a salt is always a good idea. However, I don't like the 
> static value.
> 
> I just commited a modified version of setup.php (r629) which uses hashed 
> and salted passwords (sorry, no pepper ;-)
> 
> The salt is a md5-hash computed from the remote IP, the time and a 
> random value. This might not be cyrptically perfect, but I doubt there 
> will be two postfixadmin installations using the same salt ;-)
> (Of course, when checking against the password in config.inc.php, the 
> salt is read from $CONF.)
> 
> The salt and the password are then hashed with sha1.
> 
> If someone enters a wrong setup password, he will get the hash of 
> his/her password displayed copy&paste ready for inclusion in 
> config.inc.php.
> 
> 
> Please proofread my code - this is highly security relevant, therefore 
> another pair of eyes are a good idea. Also test setup.php with valid 
> and invalid setup passwords.
> 
> Note: I'll remove the check for $CONF['setup_password'] from common.php 
> again because:
> - it's no longer really needed - no hashed password will result in 
>   something simple like "changeme" or an empty string
> - checking the setup_password in setup.php (the only place where it is 
>   used) is enough
> - blocking the whole postfixadmin just because the setup password has 
>   not been set (= current behaviour) will cause lots of needless 
>   problems if someone upgrades from a previous version.
> - The admin _will_ setup a password for sure as soon as he needs to 
>   create a super-admin via setup.php ;-)
> - (if I missed an argument why to keep the check in common.php, please 
>   speak up!)
> 
> I also think that we no longer need to use the "developer hack"
>     $CONF['configured'] = 'I_know_the_risk_of_not_deleting_setup.php'
> and should remove the code sections checking for it (index.php, 
> login.php).

I agree.

I'll try and review the code shortly; I did wonder if the
setup_password would be better off stored in the database, and we just
supply a trivial 'passwd' type script which (when run) allows 'root'
to set/change it?

At the very least, I suspect we need to make it easy for people to
generate the hashed value.... else we'll have zillions of forum posts.

David.

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] config.local.php not being read.

[Christian B. <pos...@cb...>]

Hello,

Am Donnerstag, 16. April 2009 schrieb David Goodwin:
> Christian Boltz wrote :
> > Am Dienstag, 14. April 2009 schrieb David Goodwin:

> > Note: I'll remove the check for $CONF['setup_password'] from
> > common.php again because:

I've just seen that you have removed the check if the setup_password 
is "changeme" - but you have kept the check if it is set at all.

I'd vote to remove this check also (because it will cause problems [aka 
lock postfixadmin] on upgrade if the old config.inc.php is still used) 
and adds no security.

Any objections?

> > I also think that we no longer need to use the "developer hack"
> >     $CONF['configured'] =
> > 'I_know_the_risk_of_not_deleting_setup.php' and should remove the
> > code sections checking for it (index.php, login.php).

(still ToDo)

> I'll try and review the code shortly; I did wonder if the
> setup_password would be better off stored in the database, and we
> just supply a trivial 'passwd' type script which (when run) allows
> 'root' to set/change it?

IMHO: No, please keep it in config.inc.php - that's the easiest and most 
secure solution I can think of.

> At the very least, I suspect we need to make it easy for people to
> generate the hashed value.... else we'll have zillions of forum
> posts.

Entering the wanted password in setup.php and copying the config sniplet 
to config.inc.php is easy enough IMHO ;-)


BTW: Any news on the "alias magic and domain admins" bug?
http://sourceforge.net/tracker/?func=detail&aid=2745147&group_id=191583&atid=937964
(That's the only release blocker I'm currently aware of...)


Regards,

Christian Boltz
-- 
> The issue here is the one of disk space... How do you know before hand
> there is enough disk space in /boot and /lib?
Err, ask Mr. Filesystem and, given your hd has turned ROM because it's
full, fail gracefully?
[> Marcus Meissner and Wolfgang Woehl in opensuse-factory]

Re: [Postfixadmin-devel] config.local.php not being read.

[David G. <da...@co...>]

> I've just seen that you have removed the check if the setup_password 
> is "changeme" - but you have kept the check if it is set at all.
> 
> I'd vote to remove this check also (because it will cause problems [aka 
> lock postfixadmin] on upgrade if the old config.inc.php is still used) 
> and adds no security.
> 
> Any objections?

No objections.

> 
> > > I also think that we no longer need to use the "developer hack"
> > >     $CONF['configured'] =
> > > 'I_know_the_risk_of_not_deleting_setup.php' and should remove the
> > > code sections checking for it (index.php, login.php).
> 
> (still ToDo)

Thought this had been dropped.. .ho hum.

> 
> > I'll try and review the code shortly; I did wonder if the
> > setup_password would be better off stored in the database, and we
> > just supply a trivial 'passwd' type script which (when run) allows
> > 'root' to set/change it?
> 

I had a look at it - and could see no obvious problems.


> 
> Entering the wanted password in setup.php and copying the config sniplet 
> to config.inc.php is easy enough IMHO ;-)
> 

Yes. It would be nice if it was more user friendly - e.g. one form to
generate the setup password, another to do the admin bit.

> 
> BTW: Any news on the "alias magic and domain admins" bug?
> http://sourceforge.net/tracker/?func=detail&aid=2745147&group_id=191583&atid=937964
> (That's the only release blocker I'm currently aware of...)

I know how to solve it; I just haven't yet.

David.
-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] config.local.php not being read.

[Christian B. <pos...@cb...>]

Hello,

Am Mittwoch, 22. April 2009 schrieb David Goodwin:
> > I've just seen that you have removed the check if the
> > setup_password is "changeme" - but you have kept the check if it is
> > set at all.
> >
> > I'd vote to remove this check also (because it will cause problems
> > [aka lock postfixadmin] on upgrade if the old config.inc.php is
> > still used) and adds no security.
>
> No objections.

Done.

> > > > I also think that we no longer need to use the "developer hack"
> > > >     $CONF['configured'] =
> > > > 'I_know_the_risk_of_not_deleting_setup.php' and should remove
> > > > the code sections checking for it (index.php, login.php).
> >
> > (still ToDo)
>
> Thought this had been dropped.. .ho hum.

Done.

This also fixes a bug that was well-hidden for developers. The old code 
was:

if (!file_exists (realpath ("./setup.php")) || $CONF['configured'] ==
        'I_know_the_risk_of_not_deleting_setup.php') {
     header ("Location: login.php");

-> No redirect was done for $CONF[configured] == TRUE because setup.php 
is not deleted anymore.

> > > I'll try and review the code shortly; I did wonder if the
> > > setup_password would be better off stored in the database, and we
> > > just supply a trivial 'passwd' type script which (when run)
> > > allows 'root' to set/change it?
>
> I had a look at it - and could see no obvious problems.

OK, good to hear.

> > Entering the wanted password in setup.php and copying the config
> > sniplet to config.inc.php is easy enough IMHO ;-)
>
> Yes. It would be nice if it was more user friendly - e.g. one form to
> generate the setup password, another to do the admin bit.

Sounds like a good idea. I'll see when I find the time to implement it.

> > BTW: Any news on the "alias magic and domain admins" bug?
> > http://sourceforge.net/tracker/?func=detail&aid=2745147&group_id=19
> >1583&atid=937964 (That's the only release blocker I'm currently
> > aware of...)
>
> I know how to solve it; I just haven't yet.

OK, then I don't need to waste time for searching for the solution ;-)


Regards,

Christian Boltz
-- 
I have the ideal solution for you to speed up the writing of
the manuals: http://www.lipsum.com/ - I am sure almost nobody
will notice the difference. ;-)   [houghi in opensuse-wiki]