| 2017-06-06 07:41:04 |
Laurent Declercq |
bug |
|
|
added bug |
| 2017-06-06 07:42:20 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these file get created from scratch and which I describe below for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix need read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group need write access to those files at any time
Currently, the following behavior has been observed.
When creating a new list on command line, using newlist as follow: '# newlist -u virtualhost foobar', the files will be created as follow
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both case, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these file get created from scratch and which I describe below for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix need read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group need write access to those files at any time
Currently, the following behavior has been observed.
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions. |
|
| 2017-06-06 07:44:05 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these file get created from scratch and which I describe below for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix need read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group need write access to those files at any time
Currently, the following behavior has been observed.
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these file get created from scratch and which I describe below for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
Currently, the following behavior has been observed.
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions. |
|
| 2017-06-06 07:44:39 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these file get created from scratch and which I describe below for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
Currently, the following behavior has been observed.
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these file get created from scratch and which I describe below for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions. |
|
| 2017-06-06 07:45:38 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these file get created from scratch and which I describe below for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these file get created from scratch and which I describe below for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are create from scratch.
Thank you. |
|
| 2017-06-06 07:46:39 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these file get created from scratch and which I describe below for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are create from scratch.
Thank you. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are create from scratch.
Thank you. |
|
| 2017-06-06 07:47:16 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are create from scratch.
Thank you. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are create from scratch.
Thank you. |
|
| 2017-06-06 07:48:40 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are create from scratch.
Thank you. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are create from scratch.
Thank you. |
|
| 2017-06-06 07:49:35 |
Laurent Declercq |
bug task added |
|
mailman (Ubuntu) |
|
| 2017-06-06 07:49:55 |
Laurent Declercq |
bug task added |
|
mailman (Debian) |
|
| 2017-06-06 07:50:36 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are create from scratch.
Thank you. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch.
Thank you. |
|
| 2017-06-06 07:51:31 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch.
Thank you. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch.
Thank you. |
|
| 2017-06-06 07:52:21 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch.
Thank you. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases.db
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch.
Thank you. |
|
| 2017-06-06 07:52:42 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases.db
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch.
Thank you. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases*
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch.
Thank you. |
|
| 2017-06-06 07:54:47 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases*
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch.
Thank you. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group (what I've done), or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases*
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch.
Thank you. |
|
| 2017-06-06 08:03:20 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group (what I've done), or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases*
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch.
Thank you. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group (what I've done), or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases*
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch. Eg:
IF NOT EXISTS aliases:
Touch data/aliases data/aliases.db with correct permissions (066x)
Add alias entries into aliases as usually
Run POSTALIAS(1) command as usually
Then, we are fine.
Thank you. |
|
| 2017-06-06 08:08:00 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group (what I've done), or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases*
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch. Eg:
IF NOT EXISTS aliases:
Touch data/aliases data/aliases.db with correct permissions (066x)
Add alias entries into aliases as usually
Run POSTALIAS(1) command as usually
Then, we are fine.
Thank you. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group (what I've done), or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases*
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on *.db file, to be sure that Mailman group has write permissions, at least when the files are created from scratch. Eg:
IF NOT EXISTS aliases:
Touch data/aliases data/aliases.db with correct permissions (066x)
Add alias entries into aliases as usually
Run POSTALIAS(1) command as usually
Then, we are fine.
Thank you. |
|
| 2017-06-06 10:13:44 |
Laurent Declercq |
description |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group (what I've done), or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases*
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on *.db file, to be sure that Mailman group has write permissions, at least when the files are created from scratch. Eg:
IF NOT EXISTS aliases:
Touch data/aliases data/aliases.db with correct permissions (066x)
Add alias entries into aliases as usually
Run POSTALIAS(1) command as usually
Then, we are fine.
Thank you. |
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman group (what I've done), or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created from scratch.
As you can see here, the Mailman data/aliases file is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases*
but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set correct permissions on *.db file, to be sure that Mailman group has write permissions, at least when the files are created from scratch. Eg:
IF NOT EXISTS aliases:
Touch data/aliases data/aliases.db with correct permissions (066x)
Add alias entries into aliases as usually
Run POSTALIAS(1) command as usually
Then, we are fine.
Thank you. |
|
| 2017-06-06 21:44:47 |
Launchpad Janitor |
branch linked |
|
lp:mailman/2.1 |
|
| 2017-06-06 21:53:47 |
Mark Sapiro |
mailman: importance |
Undecided |
Medium |
|
| 2017-06-06 21:53:47 |
Mark Sapiro |
mailman: status |
New |
Fix Committed |
|
| 2017-06-06 21:53:47 |
Mark Sapiro |
mailman: milestone |
|
2.1.25 |
|
| 2017-06-06 21:53:47 |
Mark Sapiro |
mailman: assignee |
|
Mark Sapiro (msapiro) |
|
| 2017-10-26 21:20:20 |
Mark Sapiro |
mailman: status |
Fix Committed |
Fix Released |
|
| 2017-10-27 07:36:35 |
Christian Ehrhardt |
bug |
|
|
added subscriber ChristianEhrhardt |
| 2017-10-27 07:49:11 |
Christian Ehrhardt |
mailman (Ubuntu): status |
New |
Triaged |
|
| 2017-10-27 07:49:13 |
Christian Ehrhardt |
mailman (Ubuntu): importance |
Undecided |
Low |
|
| 2017-11-02 10:54:24 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-11-02 10:54:24 |
Christian Ehrhardt |
bug task added |
|
mailman (Ubuntu Xenial) |
|
| 2017-11-02 10:54:24 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Artful |
|
| 2017-11-02 10:54:24 |
Christian Ehrhardt |
bug task added |
|
mailman (Ubuntu Artful) |
|
| 2017-11-02 10:54:24 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-11-02 10:54:24 |
Christian Ehrhardt |
bug task added |
|
mailman (Ubuntu Zesty) |
|
| 2017-11-02 10:54:37 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server Team |
| 2017-11-02 10:54:44 |
Christian Ehrhardt |
tags |
|
server-next |
|
| 2018-06-15 09:10:59 |
Christian Ehrhardt |
mailman (Ubuntu): status |
Triaged |
Fix Released |
|
| 2018-06-15 09:11:10 |
Christian Ehrhardt |
mailman (Debian): status |
New |
Fix Released |
|
| 2018-06-15 09:11:31 |
Christian Ehrhardt |
mailman (Ubuntu Xenial): status |
New |
Won't Fix |
|
| 2018-06-15 09:11:35 |
Christian Ehrhardt |
mailman (Ubuntu Artful): status |
New |
Won't Fix |
|
| 2018-06-15 09:11:37 |
Christian Ehrhardt |
mailman (Ubuntu Zesty): status |
New |
Won't Fix |
|
| 2018-06-15 09:13:09 |
Christian Ehrhardt |
tags |
server-next |
|
|
| 2018-06-15 09:13:14 |
Christian Ehrhardt |
removed subscriber Ubuntu Server |
|
|
|
