Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

several IMAP server packages (at least net-mail/uw-imap, net-mail/courier-imap
and net-mail/cyrus-imapd) install the file /etc/pam.d/imap, most of them are
different, some are not. this kind of collision should be prevented. for example,
the IMAP server net-mail/dovecot installs /etc/pam.d/dovecot, thus not colliding
with other IMAP servers' pam files.

If the packages don't have the option to override the pam 'facility', this will
involve patching the sources of all those servers...

I don't see how someone will want to have several IMAP servers. Since there is
a virtual/imapd, the collision shouldn't be possible.

Anyway, maybe I'm missing something... any ideas ?

Cheers,
Ferdy

well, if we don't want to patch them, then we should prevent them from
overwriting
other servers pam files.

I have installed cyrus-imapd, uw-imap and courier-imap side by side, mainly for
testing purposed. but that doesn't matter. the only thing that matters is that
those files collide.

btw: courier-imap provides a way to choose another PAM service.
/etc/courier-imap/imapd:
--8<--
##NAME: AUTHSERVICE:0
#
#  It's possible to authenticate using a different 'service' parameter
#  depending on the connection's port.  This only works with authentication
#  modules that use the 'service' parameter, such as PAM.  Example:
#
#  AUTHSERVICE143=imap
#  AUTHSERVICE993=imaps
--8<--
so we could just change the default there (same goes for all POP3 servers as
well!).

Well I expected courier-imap to have an 'easy' way to override it. But... what
do you suggest for the others ? Patching the sources just to override the pam
facility seems like a Bad Thing (TM) for me. ( In case they don't provide a way
to override it of course )

Cheers,
Ferdy

when we don't want to patch them, we should make sure they either block
each other, or they all don't install an own /etc/pam.d/imap file
but use a shared one, maybe from a metapackage, like net-mail/mailbase.

same goes for /etc/pam.d/imaps, pop, pop3, pop3s etc.

Installing a common pam.d/ file looks the better solution to me.

Cheers,
Ferdy

Committed mailbase-0.00-r7 which installs common pam.d files.

Cheers,
Ferdy

Made uw-imap depend on >=net-mail/mailbase-0.00-r8 and removed its pam.d stuff.
I'm doing it on cyrus-imapd right now.

courier-imap should follow the same behavior.

Cheers,
Ferdy

net-mail/cyrus-imapd-2.10.0-r1 is on CVS without pam.d stuff but with
>=net-mail/mailbase-0.00-r8 dependency.

Next i'm taking care of is qpopper.

Cheers,
Ferdy

qpopper-4.0.5-r2 modified and commited to conform this bug.

Cheers,
Ferdy

great job!
one note -- the package provides the following PAM files:
--8<--
/etc/pam.d/imap
/etc/pam.d/imap4
/etc/pam.d/imap4s
/etc/pam.d/imaps
/etc/pam.d/pop
/etc/pam.d/pop3
/etc/pam.d/pop3d
/etc/pam.d/pops
--8<--
maybe only 'imap' and 'pop' should be regular files and the others
should be just symlinks to the corresponding 'imap'/'pop' file?! like:
--8<--
/etc/pam.d/imap
/etc/pam.d/imap4 -> imap
/etc/pam.d/imap4s -> imap
/etc/pam.d/imaps -> imap
/etc/pam.d/pop
/etc/pam.d/pop3 -> pop
/etc/pam.d/pop3d -> pop
/etc/pam.d/pops -> pop
--8<--

Thanks!

Mmm... well I can find arguments in favor and against both aproaches and can't decide :(

Which one do you prefer ? Both seem ok to me and both seem bad in some manner.

Cheers,
Ferdy

please tell me about the disadvantages of either :)
I prefer the symlink solution (if it actually works with PAM) over
the multiple identical file solution.

It'll work fine with pam. The only drawback I see is that as a *user* I would
have expected them to be separate files. Anyway, a postinst message will do it.
Don't you think?

Cheers,
Ferdy

well, *why* should they be *separate* files? to my understanding, they should
all stand for almost the same, so it's expected behaviour to work the same, and
making use of symlinks clarifies this approach.
so when a user wants pop3 and pops to act differently, he/she can still remove
the symlink and create a new file with the appropriate content.
I believe it's more common to have them act the same than to act differently.

Yes... you're right I don't know what I was thinking on... changed on CVS:

----8<----
/etc/pam.d/imap
/etc/pam.d/imap4 -> /etc/pam.d/imap
/etc/pam.d/imap4s -> /etc/pam.d/imap
/etc/pam.d/imaps -> /etc/pam.d/imap
/etc/pam.d/pop
/etc/pam.d/pop3 -> /etc/pam.d/pop
/etc/pam.d/pop3s -> /etc/pam.d/pop
/etc/pam.d/pops -> /etc/pam.d/pop
----8<----

Cheers,
Ferdy

great! thanks! :-)

vimap already conforms this bug.

Still need to conform this bug:

courier-imap
popa3d
tpop3d

Metadata says you maintain those packages. Thats the reason I CCed you to this bug. mailbase-0.00-r8 is now stable because of a security bug in cyrus-imapd. Please do it ASAP.

Thanks
Ferdy

Currently tpop3d does not install anything in /etc/pam.d. Its default facility
name is "tpop3d". Should anything be changed?

If you can *easily* make it use a mailbase provided facility it'd be great.

EASILY stands for: No patches, no obscure hacks. Maybe a configure option or something like that.

If it's not easy, just leave it as it is :P

Cheers,
Ferdy

I could add a default tpop3d.conf that has one line: 
  auth-pam-facility: pop3

But I don't like this, because the user will still have to add a few other things
to the configuration file before tpop3d can work. I also don't like providing a 
configuration file that works out of the box because then the configuration will
not be as secure as it can be.

I could make tpop3d depend on mailbase, but then the user would have to notice 
/etc/pam.d/pop3 and add the line I mentioned above to the configuration file
himself.

In other words, I like the way it is right now unless someone else has a 
better suggestion.

Ok, so leave it as it is now :P No problem.

Cheers,
Ferdy

well, either add a *sane* and secure-by-default config or add another symlink
to mailbase:

/etc/pam.d/tpop3d -> /etc/pam.d/pop

I like the default config approach better, because it doesn't pollute the
mailbase package.

I agree that adding a tpop3d symlink to mailbase is unacceptable.
However, why would you prefer a default config that overrides tpop3d's default
facility + an added dependency on mailbase over just leaving things the way they
are now?

consistency. we added those mailbase symlinks in order to have *one*
authoritative pam facility for *all* pop/imap services. I see absolutely
no reason to leave tpop3d (or any other not-yet-adapted pop/imap server)
sit alone in its corner :-)

The same applies to vm-pop3d. It uses its own facility.

Cheers,
Ferdy

so, can it be changed in a config file or any other way without patching the
sources?
I have another idea: we could add the symlinks for tpop3d or vm-pop3d to the
server packages instead of the mailbase package.
explanation:

mailbase:
--8<--
/etc/pam.d/imap
/etc/pam.d/imap4 -> /etc/pam.d/imap
/etc/pam.d/imap4s -> /etc/pam.d/imap
/etc/pam.d/imaps -> /etc/pam.d/imap
/etc/pam.d/pop
/etc/pam.d/pop3 -> /etc/pam.d/pop
/etc/pam.d/pop3s -> /etc/pam.d/pop
/etc/pam.d/pops -> /etc/pam.d/pop
--8<--

tpopd3d:
--8<--
/etc/pam.d/tpop3d -> /etc/pam.d/pop
--8<--

vm-pop3d:
--8<--
/etc/pam.d/vm-pop3d -> /etc/pam.d/pop
--8<--

etc. etc....
much better approach than doing nothing or adding those server specific
symlinks to the mailbase package.

Good idea. I like it.

One other thing, what are the pop3/pop3s symlinks used for? For programs that
have a non-unique, hard-coded facility name?

yes, there are some servers using one of those, so the set currently
provided by mailbase is the most common subset of all.
also, the ones with a trailing 's' are used for the SSL secured
versions of imap/pop.

Made vm-pop3d use a symlink to /etc/pam.d/pop rather than installing a new file
in vm-pop3d-1.1.6-r1 [ ~ARCH ]. And made it depend on at least
mailbase-0.00-r8.

Please maintainers, made popa3d and courier-imap conform this bug ASAP.

Cheers,
Ferdy

Maurice, can you please update the tpop3d ebuild(s)? TIA!

I wasn't aware you were in a hurry. I was going to group it with some other 
changes, but instead I'll add a symlink to the ebuild and add mailbase as a 
dependency tonight.

I'm not in a hurry with tpop3d. I'm in a hurry with popa3d and courier-imap
since mailbase-0.00-r8 is now stable [ due to a security fix in cyrus-imap ];
and those packages are likely to collide with mailbase.

Cheers,
Ferdy

oh, sorry, I thought Fernando just missed tpop3d in his comment :-)
so, don't hurry for tpop3d then.

Sorry I'm so late in noticing this bug.

popa3d does not install an /etc/pam.d/imap, only /etc/pam.d/popa3d.

Would you now like popa3d to identify itself to pam as "pop3", not install /etc/pam.d/popa3d and depend on >=mailbase-0.00-r8? 

the simplest thing would be to make popa3d
install /etc/pam.d/popa3d as a symlink
to /etc/pam.d/pop, just like we did with
vm-pop3d.

popa3d fixed in CVS. 

Still need courier-imap to conform this bug in order to avoid shilly bug
reports.

Cheers,
Ferdy

FYI: tpop3d done

Thanks Maurice. Also changing summary to fit current state of bug.

Cheers,
Ferdy

>>> emerge (12 of 85) net-mail/mailbase-0.00-r8 to /
 * Checking for possible file collisions...
 * //etc/pam.d/pop3 exists and wasn't provided by mailbase
 * //etc/pam.d/imap exists and wasn't provided by mailbase

Just happend while upgrading. Those belong to courier-imap, but you allready know. 

You should add a more informative message, I just got the following message.

* //etc/pam.d/pop3 exists and wasn't provided by mailbase
* //etc/pam.d/imap exists and wasn't provided by mailbase

I figured there was some kind of collision with courier-imap, but I didn't know what caused the mailbase package to be installed. There should be a message like:

This package provides a common entry point for configuration files belonging to various imap-servers. And is provided to fix the problems in Bug 79240 (http://bugs.gentoo.org/show_bug.cgi?id=79240)

This could even be given in the description. I couldn't deciphre "MTA layout package"

Created an attachment (id=55183) [details]
courier-imap-pam.d-mailbase.diff

Little patch to remove pam.d files if net-mail/mailbase-0.00-r8 or later is
present.

*** Bug 89907 has been marked as a duplicate of this bug. ***

What is the status of this bug? (especially since I am encountering it...)

Well... actually the patch I proposed or a similar one should be applied to
courier-imap. It is up to robbat2. I can do it if he wants.

Cheers,
Ferdy

any progress on this? this still bombs out my install! :-/

Courier (seeing as how it includes courier-imap) is also affected. I'll fix it
this weekend if I can't get ahold of swtaylor to fix it.

Hey guys. Sorry if I'm terribly uninformed. But shouldn't mailbase just use
normal config-protected files (._cfg0000_pop) instead of dying when files other
than those it provides exist? In my case, I'm using PAM to authenticate against
MySQL, so I've got /etc/pam.d/pop and /etc/pam.d/imap files that are
non-standard. So, every time there's an upgrade to mailbase, my emerge -uDv
world fails and I have to move those files someplace and move them back after
the install. It's not like this really ruins my day or anything, but it's a
hassle, and I don't see any reason why mailbase shouldn't treat config files in
/etc/ the same way every other ebuild does. It just seems to me that etc-update
is here for exactly this purpose. Again I apologize if I'm missing something big.

(In reply to comment #48)
> Hey guys. Sorry if I'm terribly uninformed. But shouldn't mailbase just use
> normal config-protected files (._cfg0000_pop) instead of dying when files other
> than those it provides exist? In my case, I'm using PAM to authenticate against
> MySQL, so I've got /etc/pam.d/pop and /etc/pam.d/imap files that are
> non-standard. So, every time there's an upgrade to mailbase, my emerge -uDv
> world fails and I have to move those files someplace and move them back after
> the install. It's not like this really ruins my day or anything, but it's a
> hassle, and I don't see any reason why mailbase shouldn't treat config files in
> /etc/ the same way every other ebuild does. It just seems to me that etc-update
> is here for exactly this purpose. Again I apologize if I'm missing something big.


Just set your first line as:

# Provided by mailbase (dont remove this line!)

And you won't have problems anymore... once courier-imap works as expected this
check will be removed.

Cheers,
Ferdy

fixed in CVS.

Hi, I installed courier-imap today, and the bug is still there -- the ebuild
tried to overwrite my mailbase-provided /etc/pam.d/{pop3,imap} files. Why is
this bug closed? Please reopen the bug.

Antoni

Same here.

What's the status here?

(In reply to comment #53)

> What's the status here?

Dunno. Bug is there. Anyone fix it, please?

[a]

This is fixed in >=4.0.1-r2. See Bug 143830 for stabilization.

4.0.4 stable now, closing.