[mlmmj] Fwd: Bug#617242: mlmmj-make-ml does not ensure correct permissions

[mlmmj] Fwd: Bug#617242: mlmmj-make-ml does not ensure correct permissions

[Thomas Goirand]

Someone sent this against the MLMMJ package in Debian. I found it a very
valid request. I think either mlmmj-make-ml should set the umask
explicitly, or even better, perform some chmods.

Thomas

-------- Original Message --------
Subject: Bug#617242: mlmmj-make-ml does not ensure correct permissions
for created files and directories
Resent-Date: Mon, 07 Mar 2011 13:21:02 +0000,	Mon, 07 Mar 2011 13:21:05
+0000
Resent-From: Reuben Thomas <rrt@sc3d.org>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: MLMMJ packaging team <pkg-mlmmj-devel@lists.alioth.debian.org>
Date: Mon, 07 Mar 2011 13:16:46 +0000
From: Reuben Thomas <rrt@sc3d.org>
Reply-To: Reuben Thomas <rrt@sc3d.org>, 617242@bugs.debian.org
To: Debian Bug Tracking System <submit@bugs.debian.org>

Package: mlmmj
Version: 1.2.17-1
Severity: minor


I have my umask set to 0027. If I run mlmmj-make-ml with sudo, then
this umask is inherited, and used to create all the files and
directories for a new mailing list, which is wrong. The files and
directories should be explicitly chmodded to the correct permissions.

Re: [mlmmj] Fwd: Bug#617242: mlmmj-make-ml does not ensure correct

[Moritz Wilhelmy]

Hi,

With regard to mlmmj-make-ml.sh, I'd have some improvement ideas as well, one
of them being a defaults-folder from which a control directory can be
generated. I have in fact been working on this, but abandoned it because I
assumed, nobody would care anyway. I might continue working on it in future.
Any objections or other feature requests for mlmmj-make-ml? (Telling me this is
a dumb idea is perfectly fine!)

Best regards,

Moritz

Re: [mlmmj] Fwd: Bug#617242: mlmmj-make-ml does not ensure correct

[Ben Schmidt]

On 8/03/11 4:29 AM, Moritz Wilhelmy wrote:
> With regard to mlmmj-make-ml.sh, I'd have some improvement ideas as
> well, one of them being a defaults-folder from which a control
> directory can be generated. I have in fact been working on this, but
> abandoned it because I assumed, nobody would care anyway. I might
> continue working on it in future. Any objections or other feature
> requests for mlmmj-make-ml? (Telling me this is a dumb idea is
> perfectly fine!)

I like the idea. In fact, I suggested basically the same thing in
response to a related request from Thomas recently. Have a look at this:

http://mlmmj.org/archive/mlmmj/2011-01/1914.html

Another thought I just had is that it might be good to have an option to
mlmmj-make-ml to symlink rather than copy texts (though it should not
affect control).

Ben.

Re: [mlmmj] Fwd: Bug#617242: mlmmj-make-ml does not ensure correct

[Ben Schmidt]

Yeah. mlmmj-make-ml could definitely do with some enhancements like this. When 
integrating with web interfaces, control files often need to have the group set 
and be group-writable to be accessible by the webserver, too. Or even be owned by 
the webserver user. I guess most of this is looked after by the administrator 
after running mlmmj-make-ml usually, but it would probably be good for 
mlmmj-make-ml to give a more sensible starting point.

But what is most sensible?

- chown to the list owner and chmod 0[67]00 and do nothing about groups?
- chown to the list owner, chgrp to the mail system user, and chmod 0[67][67]0?
- something else?
- prompt the user about it?

Ben.



On 8/03/11 4:20 AM, Thomas Goirand wrote:
> Someone sent this against the MLMMJ package in Debian. I found it a very
> valid request. I think either mlmmj-make-ml should set the umask
> explicitly, or even better, perform some chmods.
>
> Thomas
>
> -------- Original Message --------
> Subject: Bug#617242: mlmmj-make-ml does not ensure correct permissions
> for created files and directories
> Resent-Date: Mon, 07 Mar 2011 13:21:02 +0000,	Mon, 07 Mar 2011 13:21:05
> +0000
> Resent-From: Reuben Thomas<rrt@sc3d.org>
> Resent-To: debian-bugs-dist@lists.debian.org
> Resent-CC: MLMMJ packaging team<pkg-mlmmj-devel@lists.alioth.debian.org>
> Date: Mon, 07 Mar 2011 13:16:46 +0000
> From: Reuben Thomas<rrt@sc3d.org>
> Reply-To: Reuben Thomas<rrt@sc3d.org>, 617242@bugs.debian.org
> To: Debian Bug Tracking System<submit@bugs.debian.org>
>
> Package: mlmmj
> Version: 1.2.17-1
> Severity: minor
>
>
> I have my umask set to 0027. If I run mlmmj-make-ml with sudo, then
> this umask is inherited, and used to create all the files and
> directories for a new mailing list, which is wrong. The files and
> directories should be explicitly chmodded to the correct permissions.
>
>
>
>

Re: [mlmmj] Fwd: Bug#617242: mlmmj-make-ml does not ensure correct

[Mads Martin Jørgensen]

On Tue, Mar 8, 2011 at 1:11 AM, Ben Schmidt
<mail_ben_schmidt@yahoo.com.au> wrote:
> Yeah. mlmmj-make-ml could definitely do with some enhancements like this.

mlmmj-make-ml is a very good example of a temporary solution becoming
permanent. This is just the script I hacked together when doing some
of the very first tests for 0.1.0 :)

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                 -- A. P. J.

Re: [mlmmj] Fwd: Bug#617242: mlmmj-make-ml does not ensure correct

[Thomas Goirand]

On 03/08/2011 01:29 AM, Moritz Wilhelmy wrote:
> Hi,
> 
> With regard to mlmmj-make-ml.sh, I'd have some improvement ideas as well, one
> of them being a defaults-folder from which a control directory can be
> generated.

Do you mean like a template we would store in
/etc/mlmmj/default-list-config or something similar? That's a very good
idea indeed!

> I have in fact been working on this, but abandoned it because I
> assumed, nobody would care anyway.

I do, and I would even more if this resolves the Debian bug chmod issue.

> Any objections or other feature requests for mlmmj-make-ml? (Telling me this is
> a dumb idea is perfectly fine!)

Removing the .sh from the original distribution would be welcome: adding
.sh to a shell script is forbidden in Debian, and having different
naming schemes across various Unixes is an issue for a software that
uses MLMMJ and is cross-unix (but I already extensively discussed the
issue, others pointed out that for backward compatibility, MLMMJ should
create symlinks).

On 03/08/2011 08:11 AM, Ben Schmidt wrote:
> Yeah. mlmmj-make-ml could definitely do with some enhancements like
> this. When integrating with web interfaces, control files often need to
> have the group set and be group-writable to be accessible by the
> webserver, too. Or even be owned by the webserver user. I guess most of
> this is looked after by the administrator after running mlmmj-make-ml
> usually, but it would probably be good for mlmmj-make-ml to give a more
> sensible starting point.

DTC (my web hosting control panel) calls it from dtc / dtcgrp, and it
should stay like this.

> But what is most sensible?
>
> - chown to the list owner and chmod 0[67]00 and do nothing about groups?
> - chown to the list owner, chgrp to the mail system user, and chmod
> 0[67][67]0?

I think it's fine not to do chown (the calling user should own the
folders, and you aren't always calling it when being root, so chown wont
work), but it is important to do chmod.

> - prompt the user about it?

Please don't (unless something like --interactive-please is used, which
would be btw a good option)! :)

Thomas

Re: [mlmmj] Fwd: Bug#617242: mlmmj-make-ml does not ensure correct

[Ben Schmidt]

>> Any objections or other feature requests for mlmmj-make-ml? (Telling me this is
>> a dumb idea is perfectly fine!)
>
> Removing the .sh from the original distribution would be welcome: adding
> .sh to a shell script is forbidden in Debian, and having different
> naming schemes across various Unixes is an issue for a software that
> uses MLMMJ and is cross-unix (but I already extensively discussed the
> issue, others pointed out that for backward compatibility, MLMMJ should
> create symlinks).

This has already been done in version control. Speaking of which, yeah,
patches against the current revision in VC would be easier for me to
apply than patches against the release, of course. Hg changeset patches
even easier, or an Hg or Git repo I can pull from.

All the ideas discussed around this feature are sounding good to me.

Cheers,

Ben.



>> But what is most sensible?
>>
>> - chown to the list owner and chmod 0[67]00 and do nothing about groups?
>> - chown to the list owner, chgrp to the mail system user, and chmod
>> 0[67][67]0?
>
> I think it's fine not to do chown (the calling user should own the
> folders, and you aren't always calling it when being root, so chown wont
> work), but it is important to do chmod.
>
>> - prompt the user about it?
>
> Please don't (unless something like --interactive-please is used, which
> would be btw a good option)! :)