When using the /etc/init.d/fetchmail script to start the fetchmail daemon with fetchmail-6-3.2, fetchmail displays the warning "running as root is discouraged". According to http://forums.gentoo.org/viewtopic-t-411702.html this is due to some (already fixed) security holes, but apparently the upstream devs still consider it too dangerous to be run as root. I suggest removing the init-script and instead adding a post-install-message about conifguring a cronjob or so.
I can't see a direct security impact here, so I'm reassigning to net-mail. But I like your idea, let's see what net-mail thinks about this.
I have also started seeing this warning since the update to fetchmail a couple of days ago. The userid normally used for mail processing is "nobody". The start-stop-daemon program can change to this, using the --chuid option, before it starts fetchmail. I would make small changes to /etc/conf.d/fetchmail and /etc/init.d/fetchmail so that the sysadmin can configure "nobody" (or any other userid of choice) under which to run the fetchmail daemon. This does not preclude the use of cron instead.
(In reply to comment #2) > The userid normally used for mail processing is "nobody". The start-stop-daemon > program can change to this, using the --chuid option, before it starts > fetchmail. I would make small changes to /etc/conf.d/fetchmail and > /etc/init.d/fetchmail so that the sysadmin can configure "nobody" (or any other > userid of choice) under which to run the fetchmail daemon. > > This does not preclude the use of cron instead. Well, but I think it's a far better solution, since I personally don't even have a cron daemon installed.
(In reply to comment #2) > I have also started seeing this warning since the update to fetchmail a couple > of days ago. > > The userid normally used for mail processing is "nobody". The start-stop-daemon > program can change to this, using the --chuid option, before it starts > fetchmail. I would make small changes to /etc/conf.d/fetchmail and > /etc/init.d/fetchmail so that the sysadmin can configure "nobody" (or any other > userid of choice) under which to run the fetchmail daemon. For proper security, the ebuild should add a dedicated user "fetchmail", nobody is not sufficient for my paranoid brain... Depending on your installation, a lot of stuff is already runing under "nobody". Exposing a global "/etc/fetchmailrc" with critical account data about external mail pops to an (too) often used "nobody" not desirable imho... Adding a (empty) commented "/etc/fetchmailrc" owned by fetchmail:root and chmodded 660 would be security by install and not by comment or advise. Remember, not all people who install gentoo are admins for years and overlooking details is only human. This would be pretty seamless while upgrading.
(In reply to comment #4) > > The userid normally used for mail processing is "nobody". The start-stop-daemon > > program can change to this, using the --chuid option, before it starts > > fetchmail. I would make small changes to /etc/conf.d/fetchmail and > > /etc/init.d/fetchmail so that the sysadmin can configure "nobody" (or any other > > userid of choice) under which to run the fetchmail daemon. > For proper security, the ebuild should add a dedicated user "fetchmail", nobody > is not sufficient for my paranoid brain... Depending on your installation, a > lot of stuff is already runing under "nobody". Exposing a global > "/etc/fetchmailrc" with critical account data about external mail pops to an > (too) often used "nobody" not desirable imho... > Adding a (empty) commented "/etc/fetchmailrc" owned by fetchmail:root and > chmodded 660 would be security by install and not by comment or advise. > Remember, not all people who install gentoo are admins for years and > overlooking details is only human. This would be pretty seamless while > upgrading. I don't see any real difference between using "nobody" and "fetchmail", as neither should be created with a password or login shell defined. Basically, neither userid should be crackable. On my system, which has quite a number of services running, the only use for "nobody" was by Postfix running SpamAssassin. Since I now run SpamAssassin under Amavis, the "nobody" userid is no longer used. I don't know what system services other people run as "nobody", but I suspect they are few and far between. Moreover, I would create /etc/fetchmailrc as owned by nobody:nobody [or fetchmail:????] and chmod 0400, as there is no reason for anybody other than the fetchmail service and the sysadmin to look at the file, and only the sysadmin should modify it. However, if we look at my original suggestion, it allows the sysadmin to choose whatever userid he/she wants. All it needs is the symbolic substitution added to the start-up script. Hence, I could use "nobody", you could use "fetchmail" and the chronic risk-takers could still use "root".
(In reply to comment #5) > I don't see any real difference between using "nobody" and "fetchmail", as > neither should be created with a password or login shell defined. Basically, > neither userid should be crackable. One quick thougt, if you ran a RSBAC enabled hardened System, a uniq UID is a lot more transparent... > On my system, which has quite a number of services running, the only use for > "nobody" was by Postfix running SpamAssassin. Since I now run SpamAssassin > under Amavis, the "nobody" userid is no longer used. I don't know what system > services other people run as "nobody", but I suspect they are few and far > between. > Moreover, I would create /etc/fetchmailrc as owned by nobody:nobody [or > fetchmail:????] and chmod 0400, as there is no reason for anybody other than > the fetchmail service and the sysadmin to look at the file, and only the > sysadmin should modify it. The amavisd-new ebuild installs its config this way... > However, if we look at my original suggestion, it allows the sysadmin to choose > whatever userid he/she wants. All it needs is the symbolic substitution added > to the start-up script. Hence, I could use "nobody", you could use "fetchmail" > and the chronic risk-takers could still use "root". Agreed, any solution that circumvents root usage for fetchmail is a step forward to more security in default install... ;-)
Created attachment 81565 [details, diff] Proposed patch for /etc/init.d/fetchmail This patch changes /etc/init.d/fetchmail so that fetchmail is run by the new user fetchmail. Create it like that: groupadd fetchmail mkdir -m 0700 /var/lib/fetchmail useradd -g fetchmail -d /var/lib/fetchmail -s /bin/false -c "added for fetchmail" fetchmail chown fetchmail: /var/lib/fetchmail /etc/fetchmailrc The FETCHMAILHOME is set so that fetchmail can write its pid and fetchids file in there. Be sure to delete the "set idfile" line from /etc/fetchmailrc.
(In reply to comment #7) > Created an attachment (id=81565) [edit] > Proposed patch for /etc/init.d/fetchmail This patch hard-codes two configuration values: the userid under which fetchmail is to be run; and the home directory it is to use. Both of these, IMO, rightly belong in /etc/conf.d/fetchmail.
I'm in favour of the "modify the init.d/conf.d stuff" approach, too. With regards to comment #7, I'm not sure what gain there is to moving the pidfile out of /var/run. If you leave the pidfile in the current place, then the only update to /etc/init.d/fetchmail is to specify the username to run fetchmail. Personally, I can't see the major again in making this configurable. If it is configurable, then there will need to be a local use flag for fetchmail to control the creation of the "fetchmail" user, otherwise the user is going to get created anyway (it would be just nasty for the ebuild not to create the fetchmail user, IMO). Phil
+1 Comment #7 thanks Michael. Any chance of an ebuild patch for the other mods mentioned?
Created attachment 88446 [details] fetchmail-6.3.4.ebuild Here are 3 files (ebuild, init.d script and conf.d file) to run fetchmail with its own user.
Created attachment 88447 [details] fetchmail
Created attachment 88448 [details] conf.d-fetchmail
Created attachment 88475 [details] fetchmail Removed a misplaced tab character.
Created attachment 88488 [details] fetchmail-6.3.4.ebuild Added an egrep check to determine whether to show the polling_period warning.
Created attachment 88579 [details] fetchmail-6.3.4.ebuild This ebuild patches the source code to allow /etc/fetchmailrc to be chmod 640.
My apologies, I meant chmod 460 :)
I saw the same warning and went looking... Any word on when this will make it in to a stable ebuild?
I'd also like to see fetchmail properly up and running in this manner, but, unfortunately, the ebuild didn't work out for me. First, no user named 'fetchmail' was created. Second, the results of trying to start fetchmail went as follows: # /etc/init.d/fetchmail start * Caching service dependencies ... [ ok ] * Starting fetchmail ... fetchmail: WARNING: Running as root is discouraged. String '-f' is not a valid number string. usage: fetchmail [options] [server ...] Options are as follows: -?, --help display this option help -V, --version display version info -c, --check check for messages without fetching -s, --silent work silently -v, --verbose work noisily (diagnostic output) -d, --daemon run as a daemon once per n seconds -N, --nodetach don't detach daemon process -q, --quit kill daemon process -L, --logfile specify logfile name --syslog use syslog(3) for most messages when running as a daemon --invisible don't write Received & enable host spoofing -f, --fetchmailrc specify alternate run control file -i, --idfile specify alternate UIDs file --postmaster specify recipient of last resort --nobounce redirect bounces from user to postmaster. -I, --interface interface required specification -M, --monitor monitor interface for activity --ssl enable ssl encrypted session --sslkey ssl private key file --sslcert ssl client certificate --sslcertck do strict server certificate check (recommended) --sslcertpath path to ssl certificates --sslfingerprint fingerprint that must match that of the server's cert. --sslproto force ssl protocol (ssl2/ssl3/tls1) --plugin specify external command to open connection --plugout specify external command to open smtp connection -p, --protocol specify retrieval protocol (see man page) -U, --uidl force the use of UIDLs (pop3 only) --port TCP port to connect to (obsolete, use --service) -P, --service TCP service to connect to (can be numeric TCP port) --auth authentication type (password/kerberos/ssh/otp) -t, --timeout server nonresponse timeout -E, --envelope envelope address header -Q, --qvirtual prefix to remove from local user id --principal mail service principal --tracepolls add poll-tracing information to Received header -u, --username specify users's login on server -a, --all retrieve old and new messages -K, --nokeep delete new messages after retrieval -k, --keep save new messages after retrieval -F, --flush delete old messages from server --limitflush delete oversized messages -n, --norewrite don't rewrite header addresses -l, --limit don't fetch messages over given size -w, --warnings interval between warning mail notification -S, --smtphost set SMTP forwarding host --fetchdomains fetch mail for specified domains -D, --smtpaddress set SMTP delivery domain to use --smtpname set SMTP full name username@domain -Z, --antispam, set antispam response values -b, --batchlimit set batch limit for SMTP connections -B, --fetchlimit set fetch limit for server connections --fetchsizelimit set fetch message size limit --fastuidl do a binary search for UIDLs -e, --expunge set max deletions between expunges -m, --mda set MDA to use for forwarding --bsmtp set output BSMTP file --lmtp use LMTP (RFC2033) for delivery -r, --folder specify remote folder name --showdots show progress dots even in logfiles [ !! ]
Hi, I just noticed that the ebuild also did not change the permissions of /etc/fetchmailrc, either. Alex
(In reply to comment #19) > no user named 'fetchmail' was created. The ebuild calls enewuser in pkg_setup, and ewarns about the file permissions. Are you sure you're using the bottom-most ebuild (attachment #88579 [details])?
Hi, This is working nicely, though I had to copy fetchmail-6.2.5-broken-headers.patch into /usr/local/portage/net-mail/fetchmail/files directory. It'd be nice if this was the default set-up for fetchmail. Alex
I guess, that fetchmail complain when it's run as root, but that fetchmail doesn't support switching the userid by itself - or does it? If it does support changeing the userid: well done, fetchmail developers. fetchmail can read the config, open a logfile and then drop all other priviledges. Oh, it doesn't support it? BAD BAD fetchmail developers!
Upstream opinion is that nobody should be running fetchmail as root, as it's rarely necessary - it usually suffices to install the MDA, such as maildrop, as set-uid root and run fetchmail as "nobody" or some other unprivileged account. This prevents potential future errors from compromising the whole system.
Fetchmail requires /etc/fetchmailrc to have permissions 0710 and ownership by user running fetchmail, while stuff in /etc is supposed to be only writable by root. Having that file with permissions 0510, owned by for example fetchmail:root is silly. I saw the rcfile_y.{c,y} sed tweak in attached ebuild, but I don't want to deviate from original source any more. By the way, Matthias, can you as an upstream maintainer comment on the broken-headers patch?
Andrej, I'm not a gentoo user, could you forward the borken-headers patch to my mail address?
fetchmail-6.2.5-broken-headers.patch is available at http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/fetchmail/files/
Thanks, Paul. I'll comment on the patch later.
(In reply to comment #26) > Andrej, I'm not a gentoo user, could you forward the borken-headers patch to my > mail address? > Sorry, my mistake. (In reply to comment #27) > fetchmail-6.2.5-broken-headers.patch is available at > http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/fetchmail/files/ > The patch was introduced and discussed in https://bugs.gentoo.org/show_bug.cgi?id=34788
As to the broken-headers patch: There are reasons to pick either policy. Being picky avoids the worst stuff from hitting the MDA or MTA that fetchmail injects into; on the other side, this means that messages that the system behind fetchmail could cope with may be dropped. The problematic part is that I, as upstream, am not aware how much of a real-world problem this is, and how much of a real-world problem embedded NUL-bytes still are. I'm very much inclined to leave fetchmail 6.3.X alone and make changes affecting behavior for the next minor or major release only (i. e. 6.4 or 7.0, I've not yet made up my mind how I'm gonna call it -- depends on how intrusive the changes will be).
(In reply to comment #30) > As to the broken-headers patch: There are reasons to pick either policy. Being > picky avoids the worst stuff from hitting the MDA or MTA that fetchmail injects > into; on the other side, this means that messages that the system behind > fetchmail could cope with may be dropped. > > The problematic part is that I, as upstream, am not aware how much of a > real-world problem this is, and how much of a real-world problem embedded > NUL-bytes still are. > > I'm very much inclined to leave fetchmail 6.3.X alone and make changes > affecting behavior for the next minor or major release only (i. e. 6.4 or 7.0, > I've not yet made up my mind how I'm gonna call it -- depends on how intrusive > the changes will be). > Thanks for your input. Perhaps a new (global or per-poll) option could be added for this, "acceptbrokenheaders" - I'm sure a less awkward name can be thought of. :) Then, we could drop this patch from Gentoo ebuild and offer fetchmail from pristine, unaltered sources to our users, which would be great. As for the issue on topic (run as a dedicated user), I don't think it's very practical, with all the limitations fetchmail places on the rcfile it's being fed, as I described in comment #25. Of course we could add several checks into the init script which would error out and inform the user about what perms/ownership /etc/fetchmailrc needs to have, if need be...
(In reply to comment #9) > I'm in favour of the "modify the init.d/conf.d stuff" approach, too. > With regards to comment #7, I'm not sure what gain there is to moving the > pidfile out of /var/run. If you leave the pidfile in the current place, then > the only update to /etc/init.d/fetchmail is to specify the username to run > fetchmail. /var/run is only writable by root (at least here on my system), and the pidfile is created by fetchmail itself, not start-stop-daemon. So it has to be somewhere else. However I'm not sure if not /var/run/fetchmail/fetchmail.pid would be more intuitive; there are already lots of subdirs in /var/run named after packages. I believe for all technical purposes this could be used as fetchmail home as well.
Created attachment 137293 [details, diff] diff for fetchmail-6.3.8-r1 /etc/init.d/fetchmail According to the fetchmail manual, the fetchmailrc file MUST be 0600 (or 0200) and owned by the calling user. non-root owned files in /etc doesn't seem to me to be a good idea. On my system, I made /etc/fetchmailrc a symlink to /var/lib/fetchmailrc, and made /var/lib/fetchmailrc 0600 fetchmail:fetchmail That way, root can still edit /etc/fetchmailrc, but the daemon won't refuse to run because it can't open the file if running as another user. I also second using /var/run/fetchmail/fetchmail.pid for the pid file -- if a human admin is looking for pid files, that's where he'll look. This patch makes it so, creating the symlink if it doesn't exist. The ebuild still needs to be altered to create the /var/lib/fetchmail and /var/run/fetchmail directories, add the fetchmail group and user, and change the directory ownership/permissions.
Any progress on this issue? The patch seems ok and I'd like to see the warning disappear as well. Tnx
Created attachment 182584 [details, diff] update to allow running fetchmail as user fetchmail creates user and group fetchmail creates /var/run/fetchmail for pidfile creates /var/lib/fetchmail for homedir
Created attachment 182585 [details, diff] update to allow running fetchmail as user fetchmail adds --chuid fetchmail forces pidfile to /var/run/fetchmail/fetchmail.pid forces .fetchids to /var/lib/fetchmail/.fetchids
(In reply to comment #35) > Created an attachment (id=182584) [edit] > update to allow running fetchmail as user fetchmail Applied as 6.3.9-r1. Thanks for the work, sorry it took so long guys. New version is ~arch on all arches. Someone that is motivated can file a stablereq bug in ~30 days. I won't be specifically looking for it so you can CC me on it and I can add arches for stabilization if needed. (just remind me why you are adding me to CC because I will probably forget)
(In reply to comment #36) > Created an attachment (id=182585) [edit] > update to allow running fetchmail as user fetchmail > > adds --chuid fetchmail > forces pidfile to /var/run/fetchmail/fetchmail.pid > forces .fetchids to /var/lib/fetchmail/.fetchids > This doesn't address fetchmailrc has to be owned by the uid running fetchmail, and not root, or fetchmail will refuse to run. Non-root-owned files in /etc is not a good idea... Either /etc/fetchmail/ or /var/lib/fetchmail/ would be good places for the fetchmail.conf file -- that way, it can be writeable by the user.
