Red Hat Bugzilla – Bug 83328
imap shouldn't require xinetd
Last modified: 2007-11-30 17:10:31 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030120 Description of problem: imap works perfectly well in the command line, where it is useful for fetching mail with fetchmail over a ssh connection (poll host protocol imap plugin "ssh host imapd" preauth ssh). I don't need xinetd in my firewall, but imapd Requires: it to let me fetch mail from it this way. If I rpm -e --nodeps xinetd, imapd still works in the command line, so please take the Requires out. Thanks in advance. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.rpm -q xinetd # not present 2.up2date -i imapd Actual Results: it installs xinetd to satisfy dependencies Expected Results: it shouldn't Additional info:
This is a custom-hack setup of UW imap. The regular usage is to have it started from xinetd, and that is what we support. By removing this requires from the package, what will happen is users will potentially be able to install imap without installing xinetd and then report bugs to us that it doesn't work. I consider your usage of imap to be very special case and not general purpose at all. The default package setup should be to have imap set up with xinetd as the supported mechanism for starting imap. Also, xinetd should be installed on every system anyway. Simply install xinetd and your problem is solved. Lets not complicate matters for the common case.
Since I'd much rather be able to install a firewall with a `minimal install' (i.e., without xinetd) while still being able to have a command line imap, how about splitting the imap binary into a separate binary package, that the main binary package containing the xinetd settings would then Require? I would provide a patch for the spec file, if you agree to this solution.
Splitting the package up for something this trivial really isn't worth it. If you're concerned about the security of xinetd being installed on a *firewall*, you really should be much more concerned about the security of imap itself. It is quite shoddy code, and has a number of security problems which are basically non-fixable without completely redesigning the application. I'm not quite sure what fetchmail using imap protocol has to do with the UW imap package though either. I use fetchmail + imap/imaps daily. $ rpm -q --whatrequires imap no package requires imap This is just asking for package splitup bloat IMHO for no real gain to the overwhelming majority of RHL/RHEL users.
Well, imap invoked from the command line still runs as the user who started it, in pre-authenticated mode, whereas imap started from xinetd runs as root, which is *far* more insecure.
pts/11 mharris@devserv:~$ ps aux |grep [i]mapd jlaska 26724 1.3 0.1 4804 2816 ? S 08:18 3:20 imapd mikem 26781 0.0 0.1 4944 3228 ? S 11:17 0:00 imapd blizzard 9588 0.0 0.1 4372 2652 ? S 11:44 0:00 imapd benl 14654 0.0 0.1 4256 2592 ? S 11:53 0:02 imapd blizzard 17689 0.0 0.1 4188 2460 ? S 12:02 0:00 imapd blizzard 21145 0.0 0.1 4168 2444 ? S 12:09 0:00 imapd I don't see imapd running as root.
Really though, anyone ultimately concerned about security, wouldn't be running ANY imap server on their firewall. A firewall is a firewall, not an imap server. UW imap is the last thing I'd want to run in a secure environment anyway. Try using dovecot instead, it's part of the distribution too now (and running on devserv also). There's also courier-imap and cyrus to choose from, although they're not in the distro.
See, the thing is exactly that I don't want imap to run as a daemon, because xinetd starts it as root. Running it from the command line, as a non-root user, it enters pre-authenticated mode, and that's something far less disruptive to run to collect e-mail delivered locally to a firewall box. I'll check whether any of the other imap implementations you mentioned offer preauth mode. Last I looked, only UW imap did it.
/usr/libexec/dovecot/imap as in FC1 can be used for preauth imap, yay!