new dovecot, selinux Problem ?
Hello List, after the last update I have a selinux "Problem" with dovecot. My system is a centos 7. After a new start from dovecot selinux block a connection. Jul 12 16:24:24 mx01 systemd: Starting Dovecot IMAP/POP3 email server... Jul 12 16:24:54 mx01 systemd: Started Dovecot IMAP/POP3 email server. Jul 12 16:24:54 mx01 dovecot: Warning: Corrected permissions for login directory /var/run/dovecot/token-login Jul 12 16:24:54 mx01 dbus[3008]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) Jul 12 16:24:55 mx01 dbus[3008]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Jul 12 16:24:55 mx01 setroubleshoot: SELinux is preventing dovecot from getattr access on the file /proc/sys/fs/suid_dumpable. For complete SELinux messages run: sealert -l c46ae6a7-64c4-49a7-9e3d-477547fb6da8 Jul 12 16:24:55 mx01 python: SELinux is preventing dovecot from getattr access on the file /proc/sys/fs/suid_dumpable.#012#012* Plugin catchall (100. confidence) suggests **#012#012If you believe that dovecot should be allowed getattr access on the suid_dumpable file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'dovecot' --raw | audit2allow -M my-dovecot#012# semodule -i my-dovecot.pp#012 is this a bad Error? When I install this local Policy i have a Problem with selinux wrong policy. sealert -a /var/log/audit/audit.log 13% donetype=AVC msg=audit(1562936830.462:61868): avc: denied { getattr } for pid=31288 comm="dovecot" path="/proc/sys/fs/suid_dumpable" dev="proc" ino=35734 scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:proc_security_t:s0 tclass=file permissive=0 Invalid AVC allowed in current policy *** 100% done found 0 alerts in /var/log/audit/audit.log Can any tell / help me for a correct installation? -- mit freundliche Grüßen / best regards, Günther J. Niederwimmer
Re: Dovecot Selinux Setting
Am 08.01.2017 um 18:04 schrieb Günther J. Niederwimmer: Hello, can any tell me the correct selinux Settings for the Maildir Setting ? in the Moment I have this setting Jan 8 15:04:52 2017 from 192.168.100.100 [root@mx03 ~]# ls -Z /srv/vmail drwx--. vmail vmail unconfined_u:object_r:mail_home_rw_t:s0 example.com drwx--. vmail vmail unconfined_u:object_r:mail_home_rw_t:s0 example.at drwx--. vmail vmail unconfined_u:object_r:mail_home_rw_t:s0 eu-example.at drwx--. vmail vmail unconfined_u:object_r:mail_home_rw_t:s0 example1.com -rw-rw. vmail vmail unconfined_u:object_r:mail_home_rw_t:s0 shared- mailboxes system_u:object_r:mail_spool_t:s0 for the spool (mail_location) I mean this not correct, I have problems with sieve to enable the Link and with Sync ? system_u:object_r:mail_home_rw_t:s0 is correct for the mail user's home I can't found the correct setting with goo. Thanks for Help and a answer, Alexander
Dovecot Selinux Setting
Hello, can any tell me the correct selinux Settings for the Maildir Setting ? in the Moment I have this setting Jan 8 15:04:52 2017 from 192.168.100.100 [root@mx03 ~]# ls -Z /srv/vmail drwx--. vmail vmail unconfined_u:object_r:mail_home_rw_t:s0 example.com drwx--. vmail vmail unconfined_u:object_r:mail_home_rw_t:s0 example.at drwx--. vmail vmail unconfined_u:object_r:mail_home_rw_t:s0 eu-example.at drwx--. vmail vmail unconfined_u:object_r:mail_home_rw_t:s0 example1.com -rw-rw. vmail vmail unconfined_u:object_r:mail_home_rw_t:s0 shared- mailboxes I mean this not correct, I have problems with sieve to enable the Link and with Sync ? I can't found the correct setting with goo. Thanks for Help and a answer, -- mit freundlichen Grüssen / best regards Günther J. Niederwimmer
Re: [Dovecot] Dovecot + SELinux permission problems - Virtual user permissions?
Sorry about the delays on following up on this, I am really struggling to get somewhere, but have made some minor progress, see below. I am now starting to suspect that it may be a problem that I have a virtual user in dovecot trying to access a maildir owned by the system user. Although the maildir has full permissions (777), could it be that SELinux is blocking the virtual user access to the file through dovecot because it is owned by the system user? Thomas Harold writes: > On 6/24/2013 9:58 AM, Johnny wrote: >> Yes, /var/log/audit/ with audit.log. There are some archived logs as >> well, but no recent messages regarding dovecot perms. > > Typically you could use "sealert -a /var/log/audit/audit.log > /var/log/audit/audit.log.1" to get a feel for how many SELinux > exceptions are happening. > I found out that auditd had the wrong permissions and therefore didn't start. Setting the permissions of /var/log/audit/audit.log to 0600 enabled starting auditd. Unfortunately, audit.log doesn't log any errors with SELinux in Permissive mode (nor for Enforcing). > Also, when you say that the restorecon -R did not fix the issue, did > you check the output of "ls -Z" after running it? > I also found out that semanage didn't work initially, as there was a symbolic link in the path. Referencing the location directly, the relabelling worked, so now Maildir and all below is type mail_spool_t. , ls -Z /home/user/data1/Maildir | drwx--. user user system_u:object_r:mail_spool_t:s0 juser | | drwx--. user user system_u:object_r:mail_spool_t:s0 yggdrasil | ` > However, looking at your original message, I'm wondering why the > forward slashes are doubled up. For instance: > "/home/user/data1/Maildir//" > Good spot! I have defined different virtual users for in a 'users' file, and there was a trailing slash in the maildir location as well as a leading slash in mail folder path. I have now removed the trailing slash so there is no double slashes in the path anymore. The problem however still remains; with SELinux in Permissive, there are no issues in logging into the dovecot server. When I set it to Enforcing, the telnet session is closed immediately when trying to login with the message : telnet localhost 143 : a login [user] [password] , | * BYE Internal error occurred. Refer to server log for more information. | Connection closed by foreign host. ` >From the dovecot log (below) it looks like a write permission error. , cat /var/log/dovecot | Aug 19 23:33:29 imap-login: Info: Login: user=, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=5217, secured, session=<2AKSh1Tk1QB/AAAB> | Aug 19 23:34:11 imap(juser): Info: Connection closed in=0 out=319 | Aug 19 23:34:18 imap-login: Info: Login: user=, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=5224, secured, session=<34J+ilTk1gB/AAAB> | Aug 19 23:34:18 imap(juser): Error: chdir(/home/user/data1/Maildir//) failed: Permission denied (euid=1000(user) egid=1000(user) missing +w perm: /home/user/data1/Maildir// stat(/home/user/data1/Maildir//) failed: Permission denied) | Aug 19 23:34:18 imap(juser): Error: chdir(/home/user/data1/Maildir/) failed: Permission denied | Aug 19 23:34:18 imap(juser): Error: user juser: Initialization failed: Namespace '': stat(/home/user/data1/Maildir//juser) failed: Permission denied (euid=1000(user) egid=1000(user) missing +w perm: /home/user/data1/Maildir//juser stat(/home/user/data1/Maildir//juser) failed: Permission denied) ` , ls -Z /home/user/data1/Maildir | drwx--. user user system_u:object_r:mail_spool_t:s0 juser | | drwx--. user user system_u:object_r:mail_spool_t:s0 yggdrasil | ` Changing permissions to 777 doesn't change matters at all. Looking at the permission error in /var/log/dovecot again leads me to think that /maybe/ the issue is that I have a virtual dovecot user 'juser' which tries to read the Maildir owned by 'user'. I.e. these lines: Permission deinied: | Aug 19 23:34:18 imap(juser): Error: user juser: Initialization failed: Namespace '': stat(/home/user/data1/Maildir/juser) failed: Permission denied (euid=1000(user) egid=1000(user) missing +w perm: /home/user/data1/Maildir/juser stat(/home/user/data1/Maildir/juser) failed: Permission denied) File ownership: | drwxrwxrwx. user user system_u:object_r:mail_spool_t:s0 juser | -- Johnny
Re: [Dovecot] Dovecot + SELinux permission problems
On 6/24/2013 9:58 AM, Johnny wrote: Yes, /var/log/audit/ with audit.log. There are some archived logs as well, but no recent messages regarding dovecot perms. Typically you could use "sealert -a /var/log/audit/audit.log /var/log/audit/audit.log.1" to get a feel for how many SELinux exceptions are happening. Also, when you say that the restorecon -R did not fix the issue, did you check the output of "ls -Z" after running it? However, looking at your original message, I'm wondering why the forward slashes are doubled up. For instance: "/home/user/data1/Maildir//"
Re: [Dovecot] Dovecot + SELinux permission problems
Jan-Frode Myklebust writes: > On Sun, Jun 23, 2013 at 04:21:17PM +0100, Johnny wrote: >> >> I had thought SELinux would log something, but /var/log/audit/audit.log >> is blank... > > Are you running auditd? I believe that if you're not running auditd, the > denials should be logged to the kernel ring buffer. It seems auditd is not running and not happy to start; , systemctl status auditd.service | Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled) | Active: failed (Result: exit-code) since Mon, 24 Jun 2013 04:28:28 +0100; 6s ago | Process: 5139 ExecStartPost=/sbin/auditctl -R /etc/audit/audit.rules (code=exited, status=0/SUCCESS) | Process: 5136 ExecStart=/sbin/auditd -n (code=exited, status=6) | CGroup: name=systemd:/system/auditd.service ` > Does "dmesg" show any denials ? Nope, all it shows is turning on/off SELinux (I tried accessing the mail prior and post changing SElinux status) , | [ 767.835481] type=1404 audit(1372044152.923:10): enforcing=0 old_enforcing=1 auid=1000 ses=1 | [ 777.110187] type=1404 audit(1372044162.218:11): enforcing=1 old_enforcing=0 auid=1000 ses=1 ` > Likely dovecot doesn't have access user_home_dir_t/user_home_t. Is all > users maildirs below /home/user/data1/Maildir/ ? All users maildirs are under the same location, e.g. , ls -Z | drwx--. user user system_u:object_r:mnt_t:s0 mailaccountA | drwx--. user user system_u:object_r:mnt_t:s0 mailaccountB | drwx--. user user unconfined_u:object_r:mnt_t:s0 mailaccountC | drwx--. user user unconfined_u:object_r:mnt_t:s0 mailaccountD ` > If so, you can probably fix this by creating a labeling rule for this, > and re-label everything below this directory: > > semanage fcontext -a -t mail_spool_t "/home/user/data1/Maildir(/.*)?" > restorecon -R /home/user/data1/Maildir No luck with using this. I will look into this more tomorrow and hopefully locate some logs. -- Johnny
Re: [Dovecot] Dovecot + SELinux permission problems
On Sun, Jun 23, 2013 at 04:21:17PM +0100, Johnny wrote: > > I had thought SELinux would log something, but /var/log/audit/audit.log > is blank... Are you running auditd? I believe that if you're not running auditd, the denials should be logged to the kernel ring buffer. Does "dmesg" show any denials ? Likely dovecot doesn't have access user_home_dir_t/user_home_t. Is all users maildirs below /home/user/data1/Maildir/ ? If so, you can probably fix this by creating a labeling rule for this, and re-label everything below this directory: semanage fcontext -a -t mail_spool_t "/home/user/data1/Maildir(/.*)?" restorecon -R /home/user/data1/Maildir -jf
[Dovecot] Dovecot + SELinux permission problems
Hi, I have set-up dovecot on a F17 box and am encountering weirdnesses with SELinux (who isn't??). Again, I am trying to refrain from disabling SWLinux all together, however tempting, but am stuck in troubleshooting and hope for some ideas... With SELinux set to permissive, I can connect to dovecot and log in to access my mail as expected. With SELinux enforcing, I can connect to dovecot, but cannot login to access mail. The log states , log_path = /var/log/dovecot (set in 10-logging.conf) | Jun 23 15:43:58 imap-login: Info: Login: user=, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=15189, secured, session= | Jun 23 15:43:58 imap(johndoe): Error: chdir(/home/user/data1/Maildir//) failed: Permission denied (euid=1000(user) egid=1000(user) missing +w perm: /home/user/data1/Maildir// stat(/home/user/data1/Maildir//) failed: Permission denied) | Jun 23 15:43:58 imap(johndoe): Error: chdir(/home/user/data1/Maildir/) failed: Permission denied | Jun 23 15:43:58 imap(johndoe): Error: user johndoe: Initialization failed: Namespace '': stat(/home/user/data1/Maildir//johndoe) failed: Permission denied (euid=1000(user) egid=1000(user) missing +w perm: /home/user/data1/Maildir//johndoe stat(/home/user/data1/Maildir//johndoe) failed: Permission denied) | Jun 23 15:43:58 imap(johndoe): Error: Invalid user settings. Refer to server log for more information. ` Only thing I can grasp is *write permission* error. ls -l on the Maildirs shows this should not be the case for uid 1000. , ls -l | drwxrwxr-x. 11 user user 4096 Jul 8 2012 Maildir | \> drwx--. 19 user user 4096 Feb 5 09:04 johndoe ` I have no idea what the server log is referring to, in the debug log I get , debug_log_path = /var/log/dovecot_debug (set in 10-logging.conf) | Jun 23 15:43:58 imap: Debug: Added userdb setting: mail=maildir:~/johndoe | Jun 23 15:43:58 imap(johndoe): Debug: Effective uid=1000, gid=1000, home=/home/user/data1/Maildir/ | Jun 23 15:43:58 imap(johndoe): Debug: Namespace inbox: type=private, prefix=, sep=., inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:~/johndoe | Jun 23 15:43:58 imap(johndoe): Debug: maildir++: root=/home/user/data1/Maildir//johndoe, index=, control=, inbox=/home/user/data1/Maildir//johndoe, alt= ` I had thought SELinux would log something, but /var/log/audit/audit.log is blank... Where to go from here?? Any ideas appreciated... -- Johnny
[Dovecot] selinux rules for dovecot
I am running selinux in permissive mode on my new mail server, in part because of dovecot. I would really like to use selinux, but I suspect it may be a challenge. My setup is on Centos 6.3 with dovecot using mysql for virutal domains and users. I am looking for a set of definitive selinux instructions, not a pointer to selinux tutorial. Here are examples of what I am seeing: Feb 27 16:46:08 klovia kernel: type=1400 audit(1362001568.770:33468): avc: denied { search } for pid=2994 comm="dict" name="mysql" dev=dm-0 ino=1705864 scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:mysqld_db_t:s0 tclass=dir Feb 27 16:46:08 klovia kernel: type=1400 audit(1362001568.770:33469): avc: denied { write } for pid=2994 comm="dict" name="mysql.sock" dev=dm-0 ino=1706116 scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:mysqld_var_run_t:s0 tclass=sock_file Feb 27 16:46:08 klovia kernel: type=1400 audit(1362001568.770:33470): avc: denied { connectto } for pid=2994 comm="dict" path="/var/lib/mysql/mysql.sock" scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:system_r:mysqld_t:s0 tclass=unix_stream_socket Feb 27 16:46:08 klovia kernel: type=1400 audit(1362001568.771:33471): avc: denied { getattr } for pid=2994 comm="dict" path="/usr/share/mysql/charsets/Index.xml" dev=dm-0 ino=395155 scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file Feb 27 16:46:08 klovia kernel: type=1400 audit(1362001568.771:33472): avc: denied { read } for pid=2994 comm="dict" name="Index.xml" dev=dm-0 ino=395155 scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
Re: [Dovecot] SELinux
--On Wednesday, June 10, 2009 12:50 PM +0200 henry ritzlmayr wrote: Am Montag, den 08.06.2009, 12:58 -0700 schrieb Kenneth Porter: I've temporarily got SELinux set to permissive mode on a fresh install on CentOS 5. It was blocking Dovecot's access to ~/mail because the files were labeled file_t. What's the correct way to label these? restorecon A naive run on /home/ken/mail didn't change the file types. I had to run "restorecon /home/ken/mail/*". I'll have to see how to do that recursively so all files under /home get labeled. (I restored a bunch of home directories from a backup of a Fedora Core 2 system, which predates SELinux and hence has no labeling.) The new labels on the mbox files are user_u:object_r:user_home_t. I'll have to see if the default CentOS 5 policy is set to be happy with that.
Re: [Dovecot] SELinux
Am Montag, den 08.06.2009, 12:58 -0700 schrieb Kenneth Porter: > I've temporarily got SELinux set to permissive mode on a fresh install on > CentOS 5. It was blocking Dovecot's access to ~/mail because the files were > labeled file_t. What's the correct way to label these? > restorecon Henry
[Dovecot] SELinux
I've temporarily got SELinux set to permissive mode on a fresh install on CentOS 5. It was blocking Dovecot's access to ~/mail because the files were labeled file_t. What's the correct way to label these?
Re: [Dovecot] SELinux and "i_stream_read() failed: Permission denied"
> On Thu, 2009-04-16 at 17:01 -0700, James Butler wrote: >> > But there's no dovecot.deliver anymore in v1.2: >> > >> > ~/cvs/dovecot-1.2/src/deliver% grep dovecot.deliver deliver >> > ~/cvs/dovecot-1.2/src/deliver% >> > >> > It is in v1.1 though. >> > >> >> I have no answer for you, except: >> >> # dovecot -n >> - 1.2.rc2: /usr/local/etc/dovecot.conf > > That doesn't necessarily mean that your deliver binary is the same > version as dovecot. For example do you happen to be using deliver binary > from another directory than /usr/local/libexec/dovecot/? Try grepping > "1.2.rc2" and "dovecot.deliver" from the deliver binary to see if it > contains either string. > >> # ls -la /tmp >> total 104 >> -rw--- 1 user dovecot 0 2009-04-15 15:47 >> dovecot.deliver..1239835658.9325.c6f5c942d0424f70 > > Hmm. Is this before you allowed unlinking or does it still happen > afterwards? These shouldn't be visible since they're created and > immediately unlinked afterwards. > D'oh! [r...@ltfs450 root]# cd /usr/local/libexec/dovecot [r...@ltfs450 dovecot]# grep dovecot.deliver deliver [r...@ltfs450 dovecot]# grep 1.2.rc2 deliver Binary file deliver matches HOWEVER, in my /etc/postfix/main.cf, I called a different binary: mailbox_command = /usr/bin/spamc -f -e /usr/libexec/dovecot/deliver [r...@ltfs450 root]# cd /usr/libexec/dovecot [r...@ltfs450 dovecot]# grep dovecot.deliver deliver Binary file deliver matches [r...@ltfs450 dovecot]# grep 1.1 deliver Binary file deliver matches I was running the old version of deliver. Thanks for clearing that up, Timo. James
Re: [Dovecot] SELinux and "i_stream_read() failed: Permission denied"
On Thu, 2009-04-16 at 17:01 -0700, James Butler wrote: > > But there's no dovecot.deliver anymore in v1.2: > > > > ~/cvs/dovecot-1.2/src/deliver% grep dovecot.deliver deliver > > ~/cvs/dovecot-1.2/src/deliver% > > > > It is in v1.1 though. > > > > I have no answer for you, except: > > # dovecot -n > - 1.2.rc2: /usr/local/etc/dovecot.conf That doesn't necessarily mean that your deliver binary is the same version as dovecot. For example do you happen to be using deliver binary from another directory than /usr/local/libexec/dovecot/? Try grepping "1.2.rc2" and "dovecot.deliver" from the deliver binary to see if it contains either string. > # ls -la /tmp > total 104 > -rw--- 1 user dovecot 0 2009-04-15 15:47 > dovecot.deliver..1239835658.9325.c6f5c942d0424f70 Hmm. Is this before you allowed unlinking or does it still happen afterwards? These shouldn't be visible since they're created and immediately unlinked afterwards. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] SELinux and "i_stream_read() failed: Permission denied"
> On Wed, 2009-04-15 at 18:55 -0700, James Butler wrote: >> > On Wed, 2009-04-15 at 16:47 -0700, James Butler wrote: >> >> "i_stream_read() failed: Permission denied" is an error message >> >> generated >> >> when a large-ish file (>128kb in my case) is attached to a message >> that >> >> has been passed to Dovecot's deliver program when SELinux is being >> >> enforced. >> > .. >> >> The problem is that deliver is not running with the correct SELinux >> >> policy >> >> to be able to write to the global /tmp directory >> > >> > BTW. Dovecot v1.2+ no longer writes to /tmp directory. Writing to /tmp >> > was pretty evil. >> >> I hear ya. I'm running v.1.2.rc2 ... is there a newer version? > > Are you sure the deliver is also from v1.2.rc2? You mentioned: > >> deliver(user): unlink(/tmp/dovecot.deliver.. \ >> 1239836047.9469.46242b1037005551) failed: Permission denied > > But there's no dovecot.deliver anymore in v1.2: > > ~/cvs/dovecot-1.2/src/deliver% grep dovecot.deliver deliver > ~/cvs/dovecot-1.2/src/deliver% > > It is in v1.1 though. > I have no answer for you, except: # dovecot -n - 1.2.rc2: /usr/local/etc/dovecot.conf # ls -la /tmp total 104 -rw--- 1 user dovecot 0 2009-04-15 15:47 dovecot.deliver..1239835658.9325.c6f5c942d0424f70 -rw--- 1 user dovecot 0 2009-04-15 15:47 dovecot.deliver..1239835664.9329.c2eb40454a80d780 -rw--- 1 user dovecot 0 2009-04-15 15:47 dovecot.deliver..1239835665.9331.b61a334c362dc35f -rw--- 1 user dovecot 0 2009-04-15 15:51 dovecot.deliver..1239835870.9420.71fa4ab59306c936 -rw--- 1 user dovecot 0 2009-04-15 15:54 dovecot.deliver..1239836046.9470.76b013baec297b2c -rw--- 1 user dovecot 0 2009-04-15 15:54 dovecot.deliver..1239836047.9469.46242b1037005551 -rw--- 1 user dovecot 0 2009-04-15 15:54 dovecot.deliver..1239836056.9482.384c6f25d95f5d2a ...etc... James
Re: [Dovecot] SELinux and "i_stream_read() failed: Permission denied"
On Wed, 2009-04-15 at 18:55 -0700, James Butler wrote: > > On Wed, 2009-04-15 at 16:47 -0700, James Butler wrote: > >> "i_stream_read() failed: Permission denied" is an error message > >> generated > >> when a large-ish file (>128kb in my case) is attached to a message that > >> has been passed to Dovecot's deliver program when SELinux is being > >> enforced. > > .. > >> The problem is that deliver is not running with the correct SELinux > >> policy > >> to be able to write to the global /tmp directory > > > > BTW. Dovecot v1.2+ no longer writes to /tmp directory. Writing to /tmp > > was pretty evil. > > I hear ya. I'm running v.1.2.rc2 ... is there a newer version? Are you sure the deliver is also from v1.2.rc2? You mentioned: > deliver(user): unlink(/tmp/dovecot.deliver.. \ > 1239836047.9469.46242b1037005551) failed: Permission denied But there's no dovecot.deliver anymore in v1.2: ~/cvs/dovecot-1.2/src/deliver% grep dovecot.deliver deliver ~/cvs/dovecot-1.2/src/deliver% It is in v1.1 though. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] SELinux and "i_stream_read() failed: Permission denied"
> On Wed, 2009-04-15 at 16:47 -0700, James Butler wrote: >> "i_stream_read() failed: Permission denied" is an error message >> generated >> when a large-ish file (>128kb in my case) is attached to a message that >> has been passed to Dovecot's deliver program when SELinux is being >> enforced. > .. >> The problem is that deliver is not running with the correct SELinux >> policy >> to be able to write to the global /tmp directory > > BTW. Dovecot v1.2+ no longer writes to /tmp directory. Writing to /tmp > was pretty evil. > > I hear ya. I'm running v.1.2.rc2 ... is there a newer version?
Re: [Dovecot] SELinux and "i_stream_read() failed: Permission denied"
On Wed, 2009-04-15 at 16:47 -0700, James Butler wrote: > "i_stream_read() failed: Permission denied" is an error message generated > when a large-ish file (>128kb in my case) is attached to a message that > has been passed to Dovecot's deliver program when SELinux is being > enforced. .. > The problem is that deliver is not running with the correct SELinux policy > to be able to write to the global /tmp directory BTW. Dovecot v1.2+ no longer writes to /tmp directory. Writing to /tmp was pretty evil. signature.asc Description: This is a digitally signed message part
[Dovecot] SELinux and "i_stream_read() failed: Permission denied"
Not a problem ... sharing a solution (this time)! Please correct my understanding of the process, if required. "i_stream_read() failed: Permission denied" is an error message generated when a large-ish file (>128kb in my case) is attached to a message that has been passed to Dovecot's deliver program when SELinux is being enforced. In my case, these messages are first run through Spamassassin, then passed to deliver, however the SELinux policy that is being violated relates to deliver, and not to Spamassassin, even though I do NOT generate the errors WITHOUT running Spamassassin. I'm not going to guess as to why that is. The policies below resolve the issue, and now large-ish (even LARGE) attachments come through without a whimper with Postfix+Spamassassin+Dovecot. The problem is that deliver is not running with the correct SELinux policy to be able to write to the global /tmp directory (in my case, after receiving the big attachment from SA), even if that directory's permissions allow it. (Bless you, SELinux!) Small-ish file attachments do not trigger this deliver functionality. Here's a complete error message, and its subsequent errors in the course of delivering a large-ish message+attachment: === deliver(user): unlink(/tmp/dovecot.deliver.. \ 1239836047.9469.46242b1037005551) failed: Permission denied deliver(user): copy: i_stream_read() failed: Permission denied deliver(user): read(mail, uid=1) failed: Permission denied deliver(user): read(mail, uid=1) failed: Permission denied deliver(user): msgid=: save failed to INBOX: Internal error occurred. \ Refer to server log for more information. [2009-04-15 17:54:07] === This is the final error series received before the policies were finally updated, and shows an error during deliver's attempt to "unlink()" (remove) the temporary file. Previous errors occurred during attempts to "stat()" and "creat()" (sic) the temporary files. Basically, the "dovecot_deliver_t" context needs to be able to create, read, write and remove files in the /tmp directory ("tmp_t" context). Below, I am pasting my "local_postfix.te" SELinux policy file. It includes instructions for using it, and for figuring out how to do other SELinux policy adjustments on your own. This is my COMPLETE Postfix+Dovecot SELinux policy group. I also have policies for Spamassassin, if anyone wants them. If you are running Sendmail or another MTA instead of Postfix, you can build on what you find below and establish your own policies. I hope this proves useful. Again, please feel free to correct any misunderstandings I may be promoting with this message. Use at your own risk, please! No guarantees ... it just worked, for me. James ## NOTE: I have broken lines in the following using the standard "\" notation to fix the email format better. However the local_postfix.te file should NOT have ANY lines broken. Remove my "\" notation and keep the lines together and you should be okay. ## ### HOW TO USE THIS ######## # SELinux, Postfix, Dovecot# # SELinux needs help resolving Postfix+Dovecot context issues. # # This file + the following instructions should get you# # on your way to resolving the policies between those contexts.# # # # 1) Create this file with the data shown below: # # local_postfix.te # # 2) Compile this file:# # checkmodule -M -m -o local_postfix.mod local_postfix.te # # 3) Create SELinux policy package:# # semodule_package -o local_postfix.pp -m local_postfix.mod# # 4) Move policy package to normal SELinux modules directory: # # mv local_postfix.pp /etc/selinux/targeted/modules/active/modules/# # 5) Update kernel with new policy package:# # semodule -i \# # /etc/selinux/targeted/modules/active/modules/local_postfix.pp # # # # Test: Send mail from remote to this system. # # Check /var/log/maillog for mail errors and # # /var/log/messages & /var/log/audit/audit.log for more specific # # SELinux errors # # Also, SELinux will provide the command (sealert...) for more details # # Use the error info you see in messages (or sea
Re: [Dovecot] Dovecot/SeLinux issues after RHEL5.1 upgrade
Thanks to Marius, I've got this problem fixed! I don't know how or why, but selinux directory contexts have been altered during the update for everyone else on the system except myself (what makes it odd is that my user has the same group and permissions as everyone else). So what did the trick was to apply: chcon -t user_home_dir_t to each user's home, mail, .imap and INBOX directories. Thanks again for pointing me in the right direction, Marius! Ion - Original Message - From: "Marius ROMAN" <[EMAIL PROTECTED]> To: "Ion Soltan" <[EMAIL PROTECTED]> Sent: Monday, January 28, 2008 2:05 PM Subject: Re: [Dovecot] Dovecot/SeLinux issues after RHEL5.1 upgrade On Jan 28, 2008 9:33 PM, Ion Soltan <[EMAIL PROTECTED]> wrote: Marius, I do run the targeted policy. Are you suggesting a reinstall of the RPM? Thank you, Ion Nope. Read http://www.dovecot.org/list/dovecot/2007-January/018989.html maybe you have the same or related problem. If this helps post your solution to the list. -- Marius
Re: [Dovecot] Dovecot/SeLinux issues after RHEL5.1 upgrade
On Jan 28, 2008 6:17 PM, Ion Soltan <[EMAIL PROTECTED]> wrote: > Hello to everyone on the list, > > I have upgraded my RHEL4 to RHEL5.1 yesterday (all updates have been applied > to it as well). I used to have dovecot v0.99.11 on the old system. Everything > was working fine. Now I have 5.1 and its respective dovecot v1.0.rc15. > > Upon upgrading to RHEL5.1, dovecot no longer works correctly. The first thing > I did after rewriting the config file for the updated version, was to check > my own email. It works fine. However, no other user on the system can check > his/hers. > > Here is what the log shows for everyone except myself: > > > Jan 27 13:56:41 warp dovecot: POP3(jj): open() failed with file > /home/jj/mail/.imap/INBOX/dovecot.index.log: Permission denied > Jan 27 13:56:41 warp dovecot: POP3(jj): open() failed with file > /home/jj/mail/.imap/INBOX/dovecot.index.log: Permission denied > Jan 27 13:56:41 warp dovecot: POP3(jj): Couldn't open INBOX: Internal error > occurred. Refer to server log for more information. [2008-01-27 13:56:41] > > > There are NO complaints reported by selinux in the logs. If I setenforce 0 > (disable selinux), everything is working fine for everyone. > > If I disable selinux monitoring on dovecot (setsebool dovecot_disable_trans > 1), nothing changes, which makes me think that something else is causing the > problem. I do very much want to use selinux, however, I cannot figure out > what the problem is and I have been trying for many hours. Can anyone help? > > Thanks, > Ion Maybe the new policy (from rpm) was not immediately applied. Do you run targeted policy ? -- Marius
[Dovecot] Dovecot/SeLinux issues after RHEL5.1 upgrade
Hello to everyone on the list, I have upgraded my RHEL4 to RHEL5.1 yesterday (all updates have been applied to it as well). I used to have dovecot v0.99.11 on the old system. Everything was working fine. Now I have 5.1 and its respective dovecot v1.0.rc15. Upon upgrading to RHEL5.1, dovecot no longer works correctly. The first thing I did after rewriting the config file for the updated version, was to check my own email. It works fine. However, no other user on the system can check his/hers. Here is what the log shows for everyone except myself: Jan 27 13:56:41 warp dovecot: POP3(jj): open() failed with file /home/jj/mail/.imap/INBOX/dovecot.index.log: Permission denied Jan 27 13:56:41 warp dovecot: POP3(jj): open() failed with file /home/jj/mail/.imap/INBOX/dovecot.index.log: Permission denied Jan 27 13:56:41 warp dovecot: POP3(jj): Couldn't open INBOX: Internal error occurred. Refer to server log for more information. [2008-01-27 13:56:41] There are NO complaints reported by selinux in the logs. If I setenforce 0 (disable selinux), everything is working fine for everyone. If I disable selinux monitoring on dovecot (setsebool dovecot_disable_trans 1), nothing changes, which makes me think that something else is causing the problem. I do very much want to use selinux, however, I cannot figure out what the problem is and I have been trying for many hours. Can anyone help? Thanks, Ion