Re: [fetchmail-devel] Drop privileges

[Sunil S. <sh...@bo...>]

Hi Thomas Jarosch,

Quoting from Thomas Jarosch's mail on Fri, Mar 27, 2009:
> attached is a patch which allows fetchmail to drop root privileges
> and run inside a chroot. The idea is to read the config file as root (as it 
> contains passwords) and setup the logging. The root privileges get dropped 
> after initialization.
> 
> All new features are optional. This will leave a stale lockfile after
> the fetchmail run (not enough privileges to write to /var/run or even
> not accessible inside the chroot), fetchmail perfectly
> handles that on the next invocation.
> 
> Upstream integration or feedback is welcome :-)
> The patch is against fetchmail 6.3.9.

Here are some thoughts on the options in your patch.


The run_chroot option:

The patch does not handle files which are being opened after chroot.
Any file opened after the chroot will be in the wrong location. For
example, in this invocation with your patch:

# fetchmail --run_chroot /home/user --logfile /home/user/fetchmail.logs \
    --idfile /home/user/.fetchids --bsmtp /home/user/bsmtp.file \
    --preconnect '/home/user/preconnect.py script-arguments'

the logfile is being opened before the chroot, the bsmtp file is being
opened after the chroot (i.e. /home/user/home/user/bsmtp.file), and
the idfile is being opened before the chroot for reading *and* after
the chroot for writing! The preconnect script is running in the
chroot.

Your patch will work correctly only if fetchmail does not open any
file or run any script after the chroot.

Also, ensuring that the preconnect script runs properly in the chroot
will be next to impossible.


The run_user and run_group options:

fetchmail is essentially a user-level daemon program. Unlike a system
daemon, it does not require special privileges to read the
configuration files and it does not bind to a reserved port. So, it is
far simpler to start fetchmail with a command like:

# su user -c fetchmail

rather than

# fetchmail --run_user user

Is it really useful to have passwords in a root-owned file? Does it
add to security? In case you really want that, you may run fetchmail
in this fashion as root:

# su user -c fetchmail -f - < /etc/fetchmailrc

The added advantage is that the lockfile is the correct place.

Another problem will be that if /etc/fetchmailrc is modified after
fetchmail is invoked with the --run_user option, it will detect the
file modification and exit because the file cannot be read again due
to dropping of privileges. Try this:

# fetchmail --run_user user --daemon 1800
[ wait for one poll to complete ]
# touch /etc/fetchmailrc
# fetchmail

This will not happen with the invocation with redirection!

-- 
Sunil Shetye.