On Wednesday 20 July 2005 02:43, Robin H. Johnson wrote:
> This problem IS fixed in ~arch:
>
> line 190 of both vpopmail-5.4.10.ebuild and
> vpopmail-5.4.9-r2.ebuild: chmod 4711 ${D}${VPOP_HOME}/bin/vchkpwAhh okay, that explains things a bit. I'm using x86, which means 5.4.6. > So if this is still a problem in arch, but works in ~arch, you > SHOULD file a bug report. Why not just wait for the newer releases to make it to arch? > However the original reasoning for vchkpw NOT being setuid was > that setuid is NOT always needed depending on which backend you > are using. I can confirm that - bincimap and qmail-pop3d run as root, so the setuid bit is not necessary. I believe this is also the case for dovecot 1.0 beta releases, though there are no ebuilds for them so I haven't yet tested (<1.0 releases use libvpopmail directly instead of the checkpassword interface). However it is necessary for any server running as a non-root user, i.e. qmail-smtpd. Thus I believe this should have the same treatment as binaries like chsh - they won't work for non-root users without the setuid bit, but running as a non-root user is generally accepted. If I want to be paranoid (which I am), I can use suidctl (which I do), and only uncomment the binary when I discover the need to. There's not really any reverse of suidctl to my awareness. Nor is there a use flag for qmail or similar on vpopmail, but the vpopmail ebuild requires qmail regardless of USE settings (postfix support is not present), so at least in the current state, since the package is built for qmail, it should assume qmail's non-root qmail-smtpd will need to access vchkpw. I would encourage making vchkpw suid even if postfix is supported and used instead of qmail, because there are other softwares (i.e. IMAP & POP servers) which have a checkpassword interface which do may not run as the root user. > And as I've mentioned before I'd like MORE reports of packages > working well before they are moved to stable arch. Without those > stable working reports I don't have any means to judge just how > much testing has been done on a package, other than my own use of > a package (and as such I do leave things longer than the 30 days, > because I don't entirely trust them). This sounds like a request for the QA team. I tend to stay away from most ~arch packages simply because most of our systems are live production servers, but I'd be happy to test-drive new ebuilds of vpopmail if it would help get new versions into the stable tree faster. Cheers, -- Casey Allen Shobe | http://casey.shobe.info [EMAIL PROTECTED] | cell 425-443-4653 AIM & Yahoo: SomeLinuxGuy | ICQ: 1494523 SeattleServer.com, Inc. | http://www.seattleserver.com -- [email protected] mailing list
