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 attachment 55183 [details, diff] 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.
