mailbase changes permissions on /var/spool/mail: mailbase-0.00-r8.ebuild: chmod 0775 ${ROOT}/var/spool/mail This prevents mail from being delivered (at least by exim), because it needs to create a lock file there. A previous version of mailbase sets the permissions to 1777, which works fine: mailbase-0.00-r5.ebuild: chmod 1777 ${ROOT}/var/spool/mail The mailbase ebuild should only set the permissions on /var/spool/mail if the directory does not exist. Reproducible: Always Steps to Reproduce: 1. (/var/spool/mail permissions are 1777) 2. emerge -u mailbase 3. (/var/spool/mail permissions are now 0775) 4. mail cannot be delivered Actual Results: 2005-04-06 17:12:27 1DIQp0-0007ql-QL == user@domain R=localuser T=local_delivery defer (13): Permission denied: creating lock file hitching post /var/mail/user.lock.domain.42540a6b.0000354a (euid=1005 egid=100) Expected Results: mailbase doesn't alter the permissions, and mail is deliveried successfully instead of failing
Dupe of Bug 16749
This is not a dupe, the other bug concerned the permissions mailbase should set up, this one is about not changing already set permissions.
CCing exim maintainers. The ideal approach would be to fix exim to work with spool permissions 0775, since these are decided on by EverybodyGentoo(tm).
0775 does not work. Users cannot access their /var/spool/mail/user unless they own the file, so exim would have to deliver as root to chown the file to the user. I don't see why it's so difficult to stop mailbase changing permissions that I set myself.
comment #4 thats wrong. It could deliver mail using a setgid mail binary for example. 1777 in /var/spool/mail is a BadThing(TM) so we won't be using it. Cheers, Ferdy
I don't care if you think 1777 is a bad thing. Running as gid mail does nothing useful, it still cannot chown the file to the user without root.
> I don't care if you think 1777 is a bad thing. Sorry to read that. But either you care or not 1777 is a really bad thing and mailbase will neither enforce nor permit unless REALLY neccesary. In fact this is not 'critical'... Cheers, Ferdy
I'll take a look at this from an exim point of view tonight. I have some ideas as to how to get it working, and I'll report back. However, forcing non-mandatory permissions on files/directories isn't a good thing, we do not know how an end-user has his system configured nor indeed why it's configured in that way so changing stuff underneath him is a 'BadThing(tm)' and imho not the gentoo way.
Looks like the chmod was set in pkg_postinst() to close bug #8029 (meaning it was to work around a portage bug). It's not clear to me that the portage bug/feature is still there, so I don't know if setting the permissions outside of the normal install is still needed. Incidentally, I agree that Gentoo should avoid enforcing permissions after the original installation of a package. We should be allowing folks to shoot themselves in the foot if they so desire.
Hi all! I changed the pkg_postinst perms code and wrote a nice ewarn if your perms differ from 775. Anyway it would be nice if exim could use the perms mailbase installs out-of-the-box. This makes mailbase-0.00-r9 (~arched of course). Please test and provide feedback. Cheers, Ferdy
Oooops... forgot to fix Cheers, Ferdy
*** Bug 95005 has been marked as a duplicate of this bug. ***
