Bug 76816 - evolution-1.1.2-1 starts an impd process as regular user when trying to connect to a local imapd server
Summary: evolution-1.1.2-1 starts an impd process as regular user when trying to conne...
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: evolution
Version: 1.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-27 12:50 UTC by Jef Spaleta
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-02-10 03:00:50 UTC

Attachments (Terms of Use)
editted evolution debugging output (34.54 KB, text/plain)
2002-12-09 16:12 UTC, Jef Spaleta
no flags Details

Description Jef Spaleta 2002-10-27 12:50:58 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830

Description of problem:
when creating an account to connect to the locally host imapd service, being run
out of xinetd, evolution starts an imapd process as the user running
evolution...this inteferes with the operation of the imapd process being run as
root from xinitd.  I can't imagine why evolution is trying to do this.

Version-Release number of selected component (if applicable): 1.1.2-1

How reproducible:

Steps to Reproduce:
1. create a new Mail Account via evo's 
      tools menu->settings menu item->mail accounts tab
2. select to recieve mail from a local imap server  (localhost or any other name
that resolves to your computer) 
3. enable the new imap server account
4. there should now be an imapd process started running as the user trying to
use evolution and evolution will not be able to connect to the local imap server


Actual Results:  evolution will be unable to connect to the local imap server
until you kill the userspace imapd procesesses.  But evo will recreate the imapd
process everytime you start evo or disable/enable the local imap account

Expected Results:  I don't think evolution is suppose to create a userspace
imapd process.  

Additional info:

Comment 1 Jeremy Katz 2002-10-27 17:17:15 UTC
No, that's perfectly normal.   Connect to imap port, xinetd spawns an imapd
process running as root.  Authenticate user.  setuid() to user so that they
can't read things which they shouldn't be able to.

In a terminal, run 'CAMEL_VERBOSE_DEBUG=1 evolution-mail', wait for it to say
that evolution-mail is ready and then start evolution.  You should see the imap
transcript in the terminal to get a real idea of how it's failing.

Comment 2 Jef Spaleta 2002-12-09 16:12:51 UTC
Created attachment 88004 [details]
editted evolution debugging output

Comment 3 Jef Spaleta 2002-12-09 16:15:14 UTC
Hi Again, sorry it took so long to get back to you with this extra info

This problem is still occuring in the latest rawhide evolution package
evolution-1.2.0-3.  Here is the output from the
CAMEL_VERBOSE_DEBUG=1 evolution-mail command that you suggested.
I've editted the output to protect the innocent.
It looks like evolution is contacting my home IMAP server(a redhat rawhide
imap-2001a-16), and finds the folder information...but the evolution gui never
lists the available folders, it only says that the server is being contacted.
Attached is the debugging output, but here is the tail end of the log

received: * LSUB () "/" mail/2002/2002-08
received: B00002 OK LSUB completed
sending : B00003 LSUB "" mail
received: B00003 OK LSUB completed
sending : B00004 LSUB "" INBOX
received: B00004 OK LSUB completed

And I created a fresh test user on the offending imap server...rawhide evo talks
to the new test user's imap account just fine.  So I think it might be some
folder/subfolder layout errors in my current imap folder structure.  I think I
should be able to get around the problem by shuffling some folders around. I'll
report back if I figure out exactly what in the folder layout reproduces this


Comment 4 Jeremy Katz 2003-02-10 03:00:50 UTC
Based on the output there, it appears like you have only subscribed folders
selected for display and you don't have anything subscribed.   You might try
reseting the options regarding using the imap namespace.

Also, it might just magically be better in 1.2.1 or later :)

Note You need to log in before you can comment on or make changes to this bug.