# fetchmail as root

## feardapenguin

I've been running fetchmail as part of my rc scripts for quite a while now (added with 'rc-update add fetchmail default').  Yesterday I upgraded fetchmail to 6.3.0 and noticed a warning on boot that fetchmail being run as root was "discouraged".

I haven't been able to find anything in the documentation on this.  Isn't the /etc/init.d script there to be used on boot?  Should it be run under 'boot' instead of 'default'?  Should only individual users start it in daemon mode?

What's the proper way to initiate fetchmail?

----------

## Rumzajs

i use it that way to, have added the line "polling_period=600" to /etc/init.d/fetchmail (to be able to set the  poling time i want)

and then add the script to the default runlevel, works well.

Whats the problem running fetchmail that way ???

----------

## feardapenguin

 *Rumzajs wrote:*   

> Whats the problem running fetchmail that way ???

 

That's what I'd like to know.  That warning didn't pop up on earlier versions.  If you aren't suppose to run it from init.d then what is the recommended way to run it?

BTW, you can add a line for the polling_period to your /etc/conf.d/fetchmail file:

```
[/etc/conf.d]# cat fetchmail

# Copyright 1999-2004 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/net-mail/fetchmail/files/conf.d-fetchmail,v 1.3 2004/07/14 23:50:30 agriffis Exp $

# Polling frequency in seconds

# (fetchmail will daemonize and check for new mail at this interval)

polling_period="600"

[/etc/conf.d]#
```

----------

## Rumzajs

well i see now why we got that warning   :Confused: 

"Fetchmail was found to contain a remotely exploitable vulnerability in the POP3 code..."

Look : http://fetchmail.berlios.de/

They have fixed it in 6.2.5.2, 6.2.5.4 and 6.3.0

you can run fetchmail as normaly user to with a cronjob : 

https://forums.gentoo.org/viewtopic-t-56633-highlight-mail.html

But this fetch only the mails for the current loged user and not for all accounts.

>BTW, you can add a line for the polling_period to your /etc/conf.d/fetchmail file: 

done, thx

----------

## smr

 *Rumzajs wrote:*   

> well i see now why we got that warning  
> 
> you can run fetchmail as normaly user to with a cronjob : 
> 
> https://forums.gentoo.org/viewtopic-t-56633-highlight-mail.html
> ...

 

On Debian it is possible to start fetchmail by /etc/init.d/fetchmail with the user fetchmail instead of the user root. Is this also possible on gentoo?

----------

## PaulBredbury

 *smr wrote:*   

> On Debian it is possible to start fetchmail by /etc/init.d/fetchmail with the user fetchmail instead of the user root.

 

Thanks, that was the motivation I needed to fix the ebuild  :Smile: 

----------

## wayt

Just upgraded to the 6.3.4 ebuild. I still see no option in /etc/conf.d/fetchmail to specify a user for the daemon to run as, see no fetchmail user added to /etc/passwd, and see 

```
fetchmail: WARNING: Running as root is discouraged.
```

 when launching the daemon from /etc/init.d/fetchmail.

Will the fixes be added to the next version, or to an 6.3.4-r1 update?

----------

## PaulBredbury

The bug is surprisingly silent after me putting the new files on it. Anway, the replacement files work great for me.

If you want to see it in Portage, then grab my files from the bug, give them a try, and post feedback on the bug.

----------

## StonedOne

Is this Topic still present?

Im Running on Version 6.3.6 and still have the "don't run on root message" ... will this be fixed or is it my configuration?

----------

## PaulBredbury

 *StonedOne wrote:*   

> Is this Topic still present?

 

I believe so. I've switched to getmail, which is run in a user's crontab.

There's nothing stopping anybody from updating the ebuild to the current version of fetchmail, and actually providing some useful feedback on the bug.

----------

## depontius

 *PaulBredbury wrote:*   

> The bug is surprisingly silent after me putting the new files on it. Anway, the replacement files work great for me.
> 
> If you want to see it in Portage, then grab my files from the bug, give them a try, and post feedback on the bug.

 

Just out of curiosity, why did you move the pidfile from /var/run to /var/lib? Granted it needs to go into a directory where the fetchmail uid has write permission, but other packages (console, cups, dbus, mysqld, and sudo on my system) have directories under /var/run, already. I presume this is some point of filesystem common practices that I'm not familiar with.

----------

## PaulBredbury

 *depontius wrote:*   

> why did you move the pidfile from /var/run to /var/lib?

 

IIRC (I don't use fetchmail any more), it was purely for the convenience of just setting up /var/lib. Feel free to update the ebuild  :Wink: 

----------

## depontius

 *PaulBredbury wrote:*   

>  *StonedOne wrote:*   Is this Topic still present? 
> 
> I believe so. I've switched to getmail, which is run in a user's crontab.
> 
> There's nothing stopping anybody from updating the ebuild to the current version of fetchmail, and actually providing some useful feedback on the bug.

 

A few spare moments cropped up, so I'm taking another quick look at this. I got to thinking, if we run fetchmail as non-root, then it also becomes feasible to run it in a chroot. At that point, fetchmail gets some serious advantages over getmail for the multidrop user. (like me) Since fetchmail injects mail into the regular system, it should be possible to run it as a non-root and still do multidrop. Since getmail does direct mail delivery, it needs to be run as root in order to do multidrop. (I thought I remembered something about fetchmail needing to run as root for multidrop, but looking through the docs now I can't see it.)

There is an option to start-stop-daemon to chroot the daemon. I rather like the idea of fetchmail in a chroot as non-root. I think I'll first simply get it running as non-root, though.

----------

## PaulBredbury

I run getmail in the user's crontab, so it runs as the user.

I haven't investigated the subtleties of multidrop, though  :Confused: 

I prefer getmail because it's just a Python script, so won't suffer from buffer problems unless Python itself does  :Smile: 

----------

## depontius

I have to run multidrop. The fetchmail documentation speaks rather insultingly of me and my ilk, and tells us to use things like ETRN or ODMR. But let's face it, if your ISP offers a POP box, you use a POP box. Besides, 6-12 months ago there was a new release of fetchmail that broke my multidrop, but at the same time it gave much better diagnostics. As a result, I was able to significantly improve my multidrop configuration, getting rid of the duplicates when my mother sent an email to both my wife and me.

Plus when Adelphia was my ISP, they didn't support any sort of SSL or TLS, so the best I could do was come up with a really odd , not very frequent polling interval, and hope that because it was on their internal network it wouldn't get sniffed. They've been bought out by Comcast, and I see by the logs that it's now using TLS. Assuming I can get non-root/chroot working along with the TLS, then I'd have no problem shortening my polling interval.

----------

