[mlmmj] Permission trouble

[mlmmj] Permission trouble

[Martin Koch Andersen]

Hi,

I have a little permission trouble setting up mlmmj alongside perl-admin.

I use postfix, which puts files as nobody. I have apache which runs as www.
I followed the instructions of the README file of both mlmmj and perl-admin.
www and nobody users have been added to group mlmmj.

I did:

chown -R nobody:mlmmj listdir/
chmod -R g+rw listdir/

I do _not_ use postfix transports. But instead regular virtual maps and aliases.

Problem is:
If I add a user using perl-admin I can not un-subscribe using mlmmj (sending list+unsubscribe@ mail).

I get the standard "you're not subscribed" mail in return. There are no permission errors in any logs.

If I add a user using list+subscribe@ mail, unsubscribe works just fine using list+unsubscribe@ mail or perl-admin.

subscribers.d>
total 6
drwxrwxr-x  15 nobody  mlmmj  512 Oct 28 22:32 ..
-rw-rw----   1 www     mlmmj   14 Oct 28 22:47 m
drwxrwxr-x   2 nobody  mlmmj  512 Oct 28 22:47 .

So if group of a file in subscribers.d/ is www unsubscribe by sending a mail to list+unsubscribe@ does not work.

list directory is owned by nobody:mlmmj. And as I read man "mlmmj-unsub", mlmmj-unsub should use that user, and hence unsubscribe should work.

PS: Typo (I think) in "man mlmmj-unsub": mlmmj-sub (instead of mlmmj-unsub) in SYNOPSIS.

-- 
Martin Koch Andersen
http://925.dk

[mlmmj] Re: Permission trouble

[Martin Koch Andersen]

On 28/10/2010 23.17, Martin Koch Andersen wrote:
> I have a little permission trouble setting up mlmmj alongside perl-admin.
> 
> I use postfix, which puts files as nobody. I have apache which runs as www.
> I followed the instructions of the README file of both mlmmj and perl-admin.
> www and nobody users have been added to group mlmmj.
> 
> [..]
> 
> Problem is:
> If I add a user using perl-admin I can not un-subscribe using mlmmj (sending list+unsubscribe@ mail).

Ah, my problem seem to be that postfix (local) does not read secondary-groups. So adding postfix to the mlmmj group made no difference.
It would have been nice with a "permission denied" message somewhere though :)

-- 
Martin Koch Andersen
http://925.dk

Re: [mlmmj] Permission trouble

[Ben Schmidt]

> I have a little permission trouble setting up mlmmj alongside perl-admin.

Mmm. Yeah. This stuff is a little challenging. It looks like you're
doing well, though. Permissions may be a red herring....

> I use postfix, which puts files as nobody. I have apache which runs as www.
> I followed the instructions of the README file of both mlmmj and perl-admin.
> www and nobody users have been added to group mlmmj.
>
> I did:
>
> chown -R nobody:mlmmj listdir/
> chmod -R g+rw listdir/

Yeah, good. Seems right.

> I do _not_ use postfix transports. But instead regular virtual maps
> and aliases.

Should be fine. That's how I run mine so far. I haven't tried
subscriptions using the web interfaces, though.

> Problem is:
> If I add a user using perl-admin I can not un-subscribe using mlmmj
> (sending list+unsubscribe@ mail).
>
> I get the standard "you're not subscribed" mail in return. There are
> no permission errors in any logs.

OK. This is strange. It suggests Mlmmj can't read the subscription file.
After you have subscribed using perl-admin, if you post to the list,
does the message get delivered?

What if you subscribe using perl-admin, and then also subscribe the same
address using list+subscribe@ mail? Do you see two, perhaps slightly
different, entries in the subscribers.d/m file?

> If I add a user using list+subscribe@ mail, unsubscribe works just
> fine using list+unsubscribe@ mail or perl-admin.

Good.

> subscribers.d>
> total 6
> drwxrwxr-x  15 nobody  mlmmj  512 Oct 28 22:32 ..
> -rw-rw----   1 www     mlmmj   14 Oct 28 22:47 m
> drwxrwxr-x   2 nobody  mlmmj  512 Oct 28 22:47 .

This looks fine.

> So if group of a file in subscribers.d/ is www unsubscribe by sending
> a mail to list+unsubscribe@ does not work.

Well, the group is right. It's only the owner that is www, and the group
permissions are fine.

> list directory is owned by nobody:mlmmj. And as I read man
> "mlmmj-unsub", mlmmj-unsub should use that user, and hence unsubscribe
> should work.

Well, mlmmj-[un]sub will only be able to use the user of the listdir if
it is run as root, which isn't the case here. Nevertheless, yes, things
should be working.

One final thought... Some OSes don't notice changes to group membership
until after a login. Maybe postfix needs to be stopped and started (and
perhaps just a reload won't work), or even the whole machine rebooted,
to get the OS to notice the change.

> PS: Typo (I think) in "man mlmmj-unsub": mlmmj-sub (instead of
> mlmmj-unsub) in SYNOPSIS.

Yep. This has already been fixed in version control. Thanks for
mentioning.

Ben.

Re: [mlmmj] Re: Permission trouble

[Ben Schmidt]

> Ah, my problem seem to be that postfix (local) does not read
> secondary-groups. So adding postfix to the mlmmj group made no
> difference.

This may just be related to my point about OSes not noticing group
membership changes until a new login. Rebooting might fix it or stopping
and starting Postfix from a newly su'ed terminal or something.

> It would have been nice with a "permission denied" message somewhere
> though :)

Mmm. Reworking Mlmmj's logging and checking system call return values
more carefully is on the to do list for attention after I get 1.2.18
out, which will hopefully be around the end of the year.

Ben.

Re: [mlmmj] Re: Permission trouble

[Martin Koch Andersen]

On 29/10/2010 13.02, Ben Schmidt wrote:

>> Ah, my problem seem to be that postfix (local) does not read
>> secondary-groups. So adding postfix to the mlmmj group made no
>> difference.
> 
> This may just be related to my point about OSes not noticing group
> membership changes until a new login. Rebooting might fix it or stopping
> and starting Postfix from a newly su'ed terminal or something.

On FreeBSD at least, and with mlmmj executed from a postfix aliases file (owned by root), the mlmmj process is started as nobody:nobody (default_privs).
Only the primary group of user nobody is read (by postfix local), thus adding user nobody to additional groups has no effect (restart or not).

Instead I've added user www to group nobody, and made listdirs recursively owned by nobody:nobody with group write permissions. Now it all works.

> 
>> It would have been nice with a "permission denied" message somewhere
>> though :)
> 
> Mmm. Reworking Mlmmj's logging and checking system call return values
> more carefully is on the to do list for attention after I get 1.2.18
> out, which will hopefully be around the end of the year.

Cool, thanks for your input. And have a splendid weekend.

-- 
Martin Koch Andersen
http://925.dk

Re: [mlmmj] Re: Permission trouble

[Marco S Hyman]

> On FreeBSD at least, and with mlmmj executed from a postfix aliases file (owned by root), the mlmmj process is started as nobody:nobody (default_privs).
> Only the primary group of user nobody is read (by postfix local), thus adding user nobody to additional groups has no effect (restart or not).
> 
> Instead I've added user www to group nobody, and made listdirs recursively owned by nobody:nobody with group write permissions. Now it all works.

Do you use NFS?  Nobody is magic to NFS and should never really be
used by anyone outside of NFS.   If your mail host acts as an NFS
server you may have given access to your mail files to every NFS
client.

Ideally, NOTHING should be owned by nobody.  It's an ID that NFS
users are mapped to when their client ID doesn't exist or isn't
allowed on the server.  If something is owned by nobody you've given
control of that file to those NFS client users.

Folks thing that nobody is somehow safe and start using nobody in
various daemons for safety.  What they've actually done is set the
daemons up to share ownership of files that really shouldn't be
shared.

/\/\arc

Re: [mlmmj] Re: Permission trouble

[Franky Van Liedekerke]

On Fri, 29 Oct 2010 12:03:59 -0700
Marco S Hyman <marc@snafu.org> wrote:

> > On FreeBSD at least, and with mlmmj executed from a postfix aliases
> > file (owned by root), the mlmmj process is started as nobody:nobody
> > (default_privs). Only the primary group of user nobody is read (by
> > postfix local), thus adding user nobody to additional groups has no
> > effect (restart or not).
> > 
> > Instead I've added user www to group nobody, and made listdirs
> > recursively owned by nobody:nobody with group write permissions.
> > Now it all works.
> 
> Do you use NFS?  Nobody is magic to NFS and should never really be
> used by anyone outside of NFS.   If your mail host acts as an NFS
> server you may have given access to your mail files to every NFS
> client.
> 
> Ideally, NOTHING should be owned by nobody.  It's an ID that NFS
> users are mapped to when their client ID doesn't exist or isn't
> allowed on the server.  If something is owned by nobody you've given
> control of that file to those NFS client users.
> 
> Folks thing that nobody is somehow safe and start using nobody in
> various daemons for safety.  What they've actually done is set the
> daemons up to share ownership of files that really shouldn't be
> shared.
> 
> /\/\arc

Hmmm ... I agree with the FreeBSD message (which by the way works on
other linux flavors as well), but I beg to differ on the nobody/NFS
story: if you don't want users to have access via NFS, don't map them
to nobody but just deny the access (even better: don't use NFS, but
that's my personal opinion).
Anyway, apache uses nobody on some OS's, postfix uses nobody for stuff
as well, etc ... "nobody" is an existing account and can thus be used
as such. What people/programs decide to do with it, is a different
story.

Franky

Re: [mlmmj] Re: Permission trouble

[Marco S Hyman]

> other linux flavors as well), but I beg to differ on the nobody/NFS
> story: if you don't want users to have access via NFS, don't map them
> to nobody but just deny the access (even better: don't use NFS, but
> that's my personal opinion).

Alas, it is more than a story.   User nobody is assumed by most
to be a user with limited access on a system.  It is also the
default mapping for UID 0 (root) on unix systems for NFS v2 and
v3.   Any file owned by nobody is therefore open by default to
root clients.  Some docs even suggest doing a mapall=nobody
for security purposes.  That only works if files that can be
accessed by remote NFS clients are NOT owned by nobody.

> Anyway, apache uses nobody on some OS's, postfix uses nobody for stuff
> as well, etc ... "nobody" is an existing account and can thus be used
> as such. What people/programs decide to do with it, is a different
> story.

There is a difference between running as user nobody and creating
files as user nobody.   Some folks get it wrong.  From a system
security point of view it's better to create a user/group per daemon
than re-using nobody.

google "user nobody exploit".   Most of the exploits found are
somewhat benign because they result is a shell login using
the "nobody" credentials.   Now throw in a bunch of files owned
by nobody.   The somewhat benign exploit just got worse.

This is getting far afield from mlmmj.  I'll drop it now.

/\/\arc

Re: [mlmmj] Re: Permission trouble

[Ben Schmidt]

> This is getting far afield from mlmmj.  I'll drop it now.

I will say one thing on the subject, though.

The README.postfix file and transport solution therein have been
designed to get around this problem. It seems that perhaps if you use
NFS you would be particularly wise to follow its advice. It's here:

http://mlmmj.org/docs/readme-postfix/

Or the current version with more about multi-domain support is here:

http://mlmmj.org/hg/mlmmj/file/tip/README.postfix

It will shortly be updated to incorporate more accurate pattern matching
in line with the discussion here:

http://mlmmj.org/bugs/bug.php?id=1

Ben.