Menu
▾
▴
fetchmail-users
|
From: Thomas W. <to...@to...> - 2005-11-11 15:01:26
|
There is this new warning "WARNING: Running as root is discouraged." which is somehow disturbing. I thought fetchmail is also intended as a system installation for multi-user mail retrieval so it's actually a designed mode to run fetchmail as root (and the message seems to be unconditional, looking at the code). Also I don't need this message when I retrieve my personal mailbox while regularly working as root on my home machine; this may not be recommended in general but it's not fetchmail to tell me that every time I retrieve my mail. Please remove the message. Kind regards, Thomas Wolff |
|
From: Rob M. <rob...@gm...> - 2005-11-11 15:35:05
|
On 11/11/05, Thomas Wolff <to...@to...> wrote:
> There is this new warning "WARNING: Running as root is discouraged."
> which is somehow disturbing.
> I thought fetchmail is also intended as a system installation
> for multi-user mail retrieval so it's actually a designed mode to
> run fetchmail as root (and the message seems to be unconditional,
> looking at the code).
Why? There is no need to run fetchmail as root. You can, and should,
run it as an unpriviledged user.
Look on the bright side, it had been proposed to refuse (as some
software does) to run as root. It was agreed that at least for 6.3
this wouldn't happen, giving people like you time to change their
configuration.
> Also I don't need this message when I retrieve my personal mailbox while
> regularly working as root on my home machine; this may not be
> recommended in general but it's not fetchmail to tell me that every
> time I retrieve my mail.
I dunno, it does encourage you to use it in a more secure manner :-)
Seriously, running anything as root that doesn't have to be run as
root is a security risk. Simply run fetchmail using a normal user
account and the message will go away.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Matthias A. <mat...@gm...> - 2005-11-17 11:02:02
|
Thomas Wolff schrieb am 2005-11-11: > There is this new warning "WARNING: Running as root is discouraged." > which is somehow disturbing. Yes, and that is deliberate. Networking clients should never run with root privileges, and fetchmail is no exception. Fetchmail does not need root privileges to forward mail, the only conceivable scenario where it needs root privileges is one where it calls an MDA for a different user. In this scenario, fetchmail should use IPC (Unix domain socket, named pipe or similar) to talk from one unprivileged process to another. This won't happen in the near future though, unless someone else finds the time to do that. > I thought fetchmail is also intended as a system installation > for multi-user mail retrieval so it's actually a designed mode to > run fetchmail as root (and the message seems to be unconditional, > looking at the code). That was how it originally worked, but the fetchmail 6.2.5 code Rob, Graham and I took over was utterly unsuitable to run as root, as you can read in <http://fetchmail.berlios.de/fetchmail-SA-2005-01.txt> (CVE-2005-2335). The 6.2.5 code was so bold as to fall back to sprintf on systems where snprintf was unavailable, which opened up even more buffer overrun possibilities. 6.3.0 uses trio_snprintf instead on such systems. There is a reason why I recommend 6.2.9-rc* to everyone, and that is many more bugfixes. > Also I don't need this message when I retrieve my personal mailbox while > regularly working as root on my home machine; this may not be I don't care if you work as root on your home machine and fetchmail pesters you with this warning. On some day in the future, fetchmail might have a model where it can give up privileges for good in the process that talk to the network and only retain privileges for MDA based setups where someone needs to run the MDA of somebody else's. This model will certainly not be the seteuid() swapping crap as that's not secure. Look at sendmail to learn some lessons about this. > recommended in general but it's not fetchmail to tell me that every > time I retrieve my mail. Evidently, it is. Sorry for my being so boldfaced. > Please remove the message. Refused. Please fix the way you work. This is not Windows, and sudo(1) works well for the few moments when you need more power than the regular user. <http://www.courtesan.com/sudo/> fetchmail is a tool for the end user who is usually untrained about systems administrations, putting up obstacles and annoyances while he works as root is the right thing to do. -- Matthias Andree |
|
From: Michelle K. <lin...@fr...> - 2005-11-18 18:58:00
|
Am 2005-11-17 11:02:01, schrieb Matthias Andree: > Thomas Wolff schrieb am 2005-11-11: > > > There is this new warning "WARNING: Running as root is discouraged." > > which is somehow disturbing. > > Yes, and that is deliberate. > > Networking clients should never run with root privileges, and fetchmail > is no exception. Fetchmail does not need root privileges to forward > mail, the only conceivable scenario where it needs root privileges is > one where it calls an MDA for a different user. If fetchmail can not started by the $USER and it run global from a script for all $USERS with "mda /usr/bin/procmail -d %T" what must I change that it continue to work To get a clue: My fetchmail wraper generates logs like 2005-09-12 12:45:01 : Processing started... 2005-09-12 12:45:02 : amina.herdam default (2: Socket) 2005-09-12 12:45:13 : athina.russel default (1: No mail) 2005-09-12 12:45:14 : ccenter default (1: No mail) 2005-09-12 12:45:18 : dgse default (1: No mail) 2005-09-12 12:45:20 : diana.seitz default (1: No mail) 2005-09-12 12:45:21 : dst default (1: No mail) 2005-09-12 12:45:23 : farahnaz.pahlavi default (1: No mail) 2005-09-12 12:45:24 : fayah.dogan default (1: No mail) 2005-09-12 12:45:28 : karima.kalaaji default (1: No mail) 2005-09-12 12:45:30 : lydia.ackermann default (1: No mail) 2005-09-12 12:45:31 : mehdi.serhane default (1: No mail) 2005-09-12 12:45:32 : michelle.konzack 0_private (1: No mail) 2005-09-12 12:45:46 : michelle.konzack 1_tdnet (0: Success) 2005-09-12 12:46:11 : michelle.konzack 3_arabeyes (1: No mail) 2005-09-12 12:46:12 : michelle.konzack 4_bts (1: No mail) 2005-09-12 12:46:15 : michelle.konzack 5_postgresql (1: No mail) 2005-09-12 12:46:16 : michelle.konzack 6_php (0: Success) 2005-09-12 12:46:24 : michelle.konzack 7_linux (0: Success) 2005-09-12 12:46:50 : michelle.konzack 8_mail (1: No mail) 2005-09-12 12:46:50 : michelle.konzack 9_debian (0: Success) 2005-09-12 12:54:34 : michelle.konzack A_misc (11: DNS) 2005-09-12 12:55:30 : michelle.konzack B_wanadoo (2: Socket) 2005-09-12 12:59:15 : michelle.konzack C_lugs (11: DNS) 2005-09-12 13:00:11 : michelle.konzack D_sun (11: DNS) 2005-09-12 13:01:07 : michelle.konzack F_tdautobuilder (2: Socket) 2005-09-12 13:02:59 : mis default (2: Socket) 2005-09-12 13:04:52 : mos default (11: DNS) 2005-09-12 13:05:48 : noor.nurani default (11: DNS) 2005-09-12 13:06:45 : omegasector default (11: DNS) 2005-09-12 13:07:43 : pmc default (11: DNS) 2005-09-12 13:08:39 : sandrine.dario default (11: DNS) 2005-09-12 13:09:35 : tamay.dogan default (2: Socket) 2005-09-12 13:13:20 : zelie.domeracki default (11: DNS) ------------------------------------------------------------------------ Availlable diskspace: Filesystem 1M-blocks Used Available Use% Mounted on /dev/hdj1 72287 45802 25751 65% /home-mail ======================================================================== Each $USER can have one or more fetchmailconfigs and now ? There is only ssmtp on the system availlable which does not support local delivery. > > I thought fetchmail is also intended as a system installation > > for multi-user mail retrieval so it's actually a designed mode to > > run fetchmail as root (and the message seems to be unconditional, Right > Refused. Please fix the way you work. This is not Windows, and sudo(1) > works well for the few moments when you need more power than the regular > user. <http://www.courtesan.com/sudo/> It can not fixed, if you need to fetch messages from cron for all the $USER of a system. > fetchmail is a tool for the end user who is usually untrained about > systems administrations, putting up obstacles and annoyances while he > works as root is the right thing to do. But if the $ENDUSER can not run fetchmail because she/he has no access and it is the system which get the messages ? My system has only courier-imap-ssl, procmail and fetchmail installed. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com) |
|
From: Matthias A. <mat...@gm...> - 2006-01-08 22:56:55
|
Michelle Konzack <lin...@fr...> writes: > Am 2005-11-17 11:02:01, schrieb Matthias Andree: >> Thomas Wolff schrieb am 2005-11-11: >> >> > There is this new warning "WARNING: Running as root is discouraged." >> > which is somehow disturbing. >> >> Yes, and that is deliberate. >> >> Networking clients should never run with root privileges, and fetchmail >> is no exception. Fetchmail does not need root privileges to forward >> mail, the only conceivable scenario where it needs root privileges is >> one where it calls an MDA for a different user. > > If fetchmail can not started by the $USER and it run global from a > script for all $USERS with "mda /usr/bin/procmail -d %T" what must > I change that it continue to work It's been a long time - désolé. I hope it's still useful :-) Set procmail setuid-root if you trust it (I don't trust it though). Better pick: Replace procmail by maildrop, compile it so that the fetchmail user is allowed to use -d, and install maildrop setuid-root. It will be a better match for courier-imap anyhow. (Maildir++, quota, same user database and all the nice parts of integration.) -- Matthias Andree |
|
From: Michelle K. <lin...@fr...> - 2006-01-19 11:27:08
|
Hallo Matthias,
Am 2006-01-08 22:56:51, schrieb Matthias Andree:
> It's been a long time - désolé. I hope it's still useful :-)
:-)
> Set procmail setuid-root if you trust it (I don't trust it though).
>
> Better pick: Replace procmail by maildrop, compile it so that the
> fetchmail user is allowed to use -d, and install maildrop setuid-root.
> It will be a better match for courier-imap anyhow. (Maildir++, quota,
> same user database and all the nice parts of integration.)
Unfortunatly "courier-maildrop" is no option for me, because I have
setup a whole "office" web interface with php5 and the filters are
set directly in procmail.
The syntax of maildrop is driving me crazy and I have not the time
and LUST to recode all from scratch again!
Greetings
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com)
|
|
From: Matthias A. <mat...@gm...> - 2006-01-20 10:56:40
|
Michelle Konzack <lin...@fr...> writes: >> Better pick: Replace procmail by maildrop, compile it so that the >> fetchmail user is allowed to use -d, and install maildrop setuid-root. >> It will be a better match for courier-imap anyhow. (Maildir++, quota, >> same user database and all the nice parts of integration.) > > Unfortunatly "courier-maildrop" is no option for me, because I have > setup a whole "office" web interface with php5 and the filters are > set directly in procmail. > > The syntax of maildrop is driving me crazy and I have not the time > and LUST to recode all from scratch again! D'accord. At least there are ways to do it without making fetchmail UID root. Personally, I prefer feeding everything through Postfix, because that gives me Amavisd-new's virus scanning capabilities and decent logging. -- Matthias Andree |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X