I have been meaning to report this for a long time but kept forgetting. Every time I update postfixadmin, 2 'wrong' things happen: Reproducible: Always Steps to Reproduce: 1. Update postfixadmin Actual Results: 1a. Note that a brand new vacation.pl-2.#.# is in place with ownership root:root 1b. Note errors in the logs if/when vacation.pl is called due to incorrect ownership 1c. Note the old vacation.pl is still there with original/correct ownership (in my case, root:vacation 2. Note any customizations to vacation.pl are gone (still in the old version) Expected Results: 1. Ownership of vacation.pl should not be changed to root:root, it should be made the same as the previous version of vacation.pl 2. vacation.pl should be monitored for config changes that can be managed by etc-update (or equivalent)
Any chance of this getting foxed for the new 2.3.7 that was recently released?
Are you using the vhosts use flag? Looking at the ebuild if use vacation; then insinto /var/spool/vacation newins VIRTUAL_VACATION/vacation.pl vacation.pl-${SLOT} fowners vacation:vacation /var/spool/vacation/vacation.pl-${SLOT} fperms 770 /var/spool/vacation/vacation.pl-${SLOT} ln -sf "${ROOT}"/var/spool/vacation/vacation.pl{-${SLOT},} we're not installing vacation.pl, but "vacation.pl-${SLOT}" and then create a symlink to it. About the permissions, it seems you may have an old vacation.pl script in the disk and that it wasn't replaced with a symlink. About protecting changes to vacation.pl, I'm not sure how we should deal with that. Do those changes require updates to configuration?
Thanks for the look-see Jorge... (In reply to Jorge Manuel B. S. Vicetto from comment #2) > Are you using the vhosts use flag? Yep... emerge --info <snip> USE="... vhosts ..." > Looking at the ebuild > > if use vacation; then > insinto /var/spool/vacation > newins VIRTUAL_VACATION/vacation.pl vacation.pl-${SLOT} > fowners vacation:vacation > /var/spool/vacation/vacation.pl-${SLOT} > fperms 770 /var/spool/vacation/vacation.pl-${SLOT} > > ln -sf "${ROOT}"/var/spool/vacation/vacation.pl{-${SLOT},} > > we're not installing vacation.pl, but "vacation.pl-${SLOT}" and then create > a symlink to it. Ok, but what does it currently do with the old one (ianap, so reading the code above, I really can't tell)? Leave it in place (I don't want it replaced/deleted). As I said, I make manual modifications to it. > About the permissions, it seems you may have an old vacation.pl script > in the disk and that it wasn't replaced with a symlink. Not that I see. Currently there is only the vacation.pl-2.3.6, and the symlink. Although, from your snippet from the ebuild - the perms are not as described. On my system, the actual vacation.pl-2.3.6 file is root:vacation, and the perms for the symlink are root:root, and it works just fine... Maybe I need to manually fix the perms, then future updates will create/preserve them properly? myhost : Mon Mar 17, 07:24:36 : ~ # ls -al /var/spool/vacation/ total 28 drwxr-xr-x 2 vacation vacation 48 Dec 23 09:50 . drwxr-xr-x 6 root root 69 Dec 23 09:50 .. lrwxrwxrwx 1 root root 38 Dec 23 09:50 vacation.pl -> //var/spool/vacation/vacation.pl-2.3.6 -rwxrwx--- 1 root vacation 25407 Jan 5 08:58 vacation.pl-2.3.6 myhost : Mon Mar 17, 07:29:59 : ~ # Hmmm... what is with the double leading slashes for the symlink?? > About protecting changes to vacation.pl, I'm not sure how we should deal > with that. Do those changes require updates to configuration? No, it is simply adding some better conditions for testing for when vacation messages should be sent. I've been trying to get the postfixadmin devs to incorporate them into the core, but there are always other changes that could easily be made that would create the same problem for someone else. Is it not possible to somehow tell etc-update to handle updates to this file?
(In reply to Charles from comment #3) > Thanks for the look-see Jorge... np > (In reply to Jorge Manuel B. S. Vicetto from comment #2) > > Are you using the vhosts use flag? > > Yep... > > emerge --info > <snip> > USE="... vhosts ..." How are you installing the package to the system with webapp-config? > > Looking at the ebuild > > > > if use vacation; then > > insinto /var/spool/vacation > > newins VIRTUAL_VACATION/vacation.pl vacation.pl-${SLOT} > > fowners vacation:vacation > > /var/spool/vacation/vacation.pl-${SLOT} > > fperms 770 /var/spool/vacation/vacation.pl-${SLOT} > > > > ln -sf "${ROOT}"/var/spool/vacation/vacation.pl{-${SLOT},} > > > > we're not installing vacation.pl, but "vacation.pl-${SLOT}" and then create > > a symlink to it. > > Ok, but what does it currently do with the old one (ianap, so reading the > code above, I really can't tell)? Leave it in place (I don't want it > replaced/deleted). As I said, I make manual modifications to it. If you have a symlink in place, it should be trying to replace it (ln -sf), but it might be failing for some reason. Please check the build log to see if there are any errors during install / merge. > > About the permissions, it seems you may have an old vacation.pl script > > in the disk and that it e dwasn't replaced with a symlink. > > Not that I see. Currently there is only the vacation.pl-2.3.6, and the > symlink. > > Although, from your snippet from the ebuild - the perms are not as described. The permissions for web applications are set by webapp-config, but since the ebuild is installing directly to /var/spool, it might need some updates to fix the permissions there. > > About protecting changes to vacation.pl, I'm not sure how we should deal > > with that. Do those changes require updates to configuration? > > No, it is simply adding some better conditions for testing for when vacation > messages should be sent. I've been trying to get the postfixadmin devs to > incorporate them into the core, but there are always other changes that > could easily be made that would create the same problem for someone else. > > Is it not possible to somehow tell etc-update to handle updates to this file? We protect config files and init scripts, we don't protect packages binaries and scripts. In this case, it seems like you should be looking at using epatch_user so you apply your changes over the original vacation.pl script. @webapps: opinions?
(In reply to Jorge Manuel B. S. Vicetto from comment #4) > How are you installing the package to the system with webapp-config? I always install the new versions to a new subdirectory rather than updating, dump/instll the db to a new one, then make sure the new version is running properly before flipping the switch (changing postfix and dovecot to point to the new one). So, assuming I'm installing 2.3.6: webapp-config -I -h pfa.example.com -d 236 postfixadmin 236 > If you have a symlink in place, it should be trying to replace it (ln -sf), > but it might be failing for some reason. Please check the build log to see > if there are any errors during install / merge. None (I get the emerge logs via email and always look at them). Here is the last one (from the 2.3.6 update): INFO: setup Package: www-apps/postfixadmin-2.3.6 Repository: gentoo Maintainer: web-apps@gentoo.org USE: abi_x86_64 amd64 elibc_glibc kernel_linux multilib mysql userland_GNU vacation vhosts xmlrpc FEATURES: preserve-libs sandbox userpriv usersandbox Adding group 'vacation' to your system ... - Groupid: next available Adding user 'vacation' to your system ... - Userid: 102 - Shell: /sbin/nologin - Home: /dev/null - Groups: vacation - GECOS: added by portage for postfixadmin LOG: install (config) htdocs/config.inc.php (info) /usr/portage/www-apps/postfixadmin/files/postinstall-en-2.3.txt (lang: en) LOG: postinst The 'vhosts' USE flag is switched ON This means that Portage will not automatically run webapp-config to complete the installation. To install postfixadmin-2.3.6 into a virtual host, run the following command: webapp-config -I -h <host> -d postfixadmin postfixadmin 2.3.6 For more details, see the webapp-config(8) man page INFO: postinst /var/spool/vacation/vacation.pl symlink was updated to: /var/spool/vacation/vacation.pl-2.3.6 > The permissions for web applications are set by webapp-config, but since the > ebuild is installing directly to /var/spool, it might need some updates to > fix the permissions there. Hmmm... not sure what you mean by 'it' ot 'there' above... It = webapp-config? The postfixadmin ebuild? > We protect config files and init scripts, we don't protect packages binaries > and scripts. In this case, it seems like you should be looking at using > epatch_user so you apply your changes over the original vacation.pl script. > > @webapps: > opinions? Thanks again... but I'm not sure how I would use it (as I said, ianap)... It isn't the end of the world, just annoying. I hate having to manually keep up with modifications like this, but it isn't like it gets updated all that often...
I don't see what we can do about this without implementing it in webapp-config separate from config protection. I think the idea here is that while config files should be changed by the user, package binaries and scripts should not, and should instead be overwritten. If the user wants to modify a script, or in the example of mediawiki install an extension, it's up to the user to use the vhosts use flag, back up the folder, and then after installing the new version copy that customized file/folder back. That's my opinion.
(In reply to Samuel Damashek from comment #6) > I don't see what we can do about this without implementing it in > webapp-config separate from config protection. I think the idea here is that > while config files should be changed by the user, package binaries and > scripts should not, and should instead be overwritten. > > If the user wants to modify a script, or in the example of mediawiki install > an extension, it's up to the user to use the vhosts use flag, back up the > folder, and then after installing the new version copy that customized > file/folder back. > > That's my opinion. I agree with you. My suggestion to use epatch_user was to allow the user to apply a patch to the original script and have portage install the modified version. Another idea regarding this particular case, is that perhaps upstream should (needs?) to split the execution and the configuration of the vacation script. So the users would configure it in a configuration file and wouldn't need to touch the script. Upstream might not be interested on this, though. PS - Depending on your mail config, you may be able to take care of the vacation config, through sieve - which might be more "flexible".
Below we have vacation:vacation on vacation.pl if use vacation; then insinto /var/spool/vacation newins VIRTUAL_VACATION/vacation.pl vacation.pl-${SLOT} fowners vacation:vacation /var/spool/vacation/vacation.pl-${SLOT} fperms 770 /var/spool/vacation/vacation.pl-${SLOT} dodoc VIRTUAL_VACATION/FILTER_README newdoc VIRTUAL_VACATION/INSTALL.md VIRTUAL_VACATION_INSTALL.md rm -r VIRTUAL_VACATION/{vacation.pl,INSTALL.md,tests,FILTER_README} || die fi but after webapp_src_install we root:root again # @FUNCTION: webapp_src_install # @DESCRIPTION: # This is the default src_install(). For now, we just make sure that root owns # everything, and that there are no setuid files.
Created attachment 734359 [details, diff] Drop vavation:vacation on vacation.pl and chmod 0755 instead of 0770 IMHO Executable vacation.pl should not be writable for vacation:vacation and 0755 on vacation.pl should fix issue with exec from none root users
postfixadmin-3.3.11 affected too, not fixed :(
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f5a00aa71288f68a50a4accc54f815a1d0dc5f56 commit f5a00aa71288f68a50a4accc54f815a1d0dc5f56 Author: Miroslav Šulc <fordfrog@gentoo.org> AuthorDate: 2022-09-18 12:36:06 +0000 Commit: Miroslav Šulc <fordfrog@gentoo.org> CommitDate: 2022-09-18 12:36:18 +0000 www-apps/postfixadmin: fixed vacation permissions in 3.3.11 Closes: https://bugs.gentoo.org/459144 Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org> .../{postfixadmin-3.3.11.ebuild => postfixadmin-3.3.11-r1.ebuild} | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
thanks for the improvement. for those having issues with vacation.pl being modified, the script has support for external configurations: # instead of changing this script, you can put your settings to /etc/mail/postfixadmin/vacation.conf # or /etc/postfixadmin/vacation.conf just use Perl syntax there to fill the variables listed above # (without the "our" keyword). Example: # $db_username = 'mail'; if (-f '/etc/mail/postfixadmin/vacation.conf') { require '/etc/mail/postfixadmin/vacation.conf'; } elsif (-f '/etc/postfixadmin/vacation.conf') { require '/etc/postfixadmin/vacation.conf'; } elsif (-f './vacation.conf') { require './vacation.conf'; }