L'uso di questo sito
autorizza anche l'uso dei cookie
necessari al suo funzionamento.
(Altre informazioni)

Friday, April 12, 2013

The strange world of SELinux and webmin

I am willing to share a few more sysdamin pains today, for the BDSM oriented people who enjoy suffering.

I am testing webmin on a CentOS 6.3 machine today. Purpose: creating a restricted web-paneled environmente where a basically skilled admin can add users, mailboxes, aliases and so on  without hosing the system or opening mile-wide holes into it. It does look doable so far except....

I want mail delivery done in Maildir-style folders under the user homedir. Procmail is the perfect tool for this, given the following /etc/procmailrc:


(Hint: the trainling slash does the trick).

Enters webmin, breakage begins.  A webmin-added user, balf, cannot have mail properly delivered, while a adduser-added user alf, can. Ostensible reason being that, in the first instance, procmail is incapable of creating the mail/ directory. The logfile trace is self-explanatory as usual:

procmail: Unable to treat as directory "/home/balf/mail"
procmail: Locking "/home/balf/mail.lock"
procmail: Error while writing to "/home/balf/_D3D.N35ZRB.localhost.localdo"
procmail: Lock failure on "/home/balf/mail.lock"
procmail: Assigning "LASTFOLDER=/home/balf/mail/"
procmail: Opening "/home/balf/mail/"
procmail: Error while writing to "/home/balf/mail"
procmail: Assigning "LASTFOLDER=/var/spool/mail/balf"
procmail: Opening "/var/spool/mail/balf"
procmail: Acquiring kernel-lock


Google brings no joy other than the usual check permissions and stuff. Which I did. The gut instinct reaction (manually creating the mail directory) just pushes the problem deeper. Some work succeds in making the users exactly the same (same permissions, on home dirs, same group, same passwd and shadow entries, same files in the home dir. So it must be something with permissions, which means....SELinux. Which I usually turn off - but forgot on this time. 'ls -Z' verifies that the homedirs of the users have indeed different context:

 # ls -Z drwx------. alf mailusers unconfined_u:object_r:user_home_dir_t:s0 alf drwx------. balf mailusers unconfined_u:object_r:home_root_t:s0 balf

So, at this point you turn off SELinux, and all is well (put SELINUX=disabled in /etc/sysconfig/selinux).

No comments: