Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 459144 - www-apps/postfixadmin - /var/spool/vacation.pl has wrong group membership after updates, modifications lost
Summary: www-apps/postfixadmin - /var/spool/vacation.pl has wrong group membership aft...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Aaron W. Swenson
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-25 12:16 UTC by tanstaafl@libertytrek.org
Modified: 2021-08-20 06:56 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Drop vavation:vacation on vacation.pl and chmod 0755 instead of 0770 (postfixadmin.patch,631 bytes, patch)
2021-08-20 06:56 UTC, Maxim Britov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description tanstaafl@libertytrek.org 2013-02-25 12:16:37 UTC
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)
Comment 1 tanstaafl@libertytrek.org 2014-03-12 13:15:01 UTC
Any chance of this getting foxed for the new 2.3.7 that was recently released?
Comment 2 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2014-03-16 16:48:43 UTC
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?
Comment 3 tanstaafl@libertytrek.org 2014-03-17 11:37:40 UTC
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?
Comment 4 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2014-03-17 12:15:51 UTC
(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?
Comment 5 tanstaafl@libertytrek.org 2014-03-17 12:37:07 UTC
(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...
Comment 6 Samuel Damashek (RETIRED) gentoo-dev 2014-03-22 15:27:30 UTC
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.
Comment 7 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2014-03-22 16:05:47 UTC
(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".
Comment 8 Maxim Britov 2021-08-18 11:54:09 UTC
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.
Comment 9 Maxim Britov 2021-08-20 06:56:04 UTC
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