[pmg-devel] code adjustment for PMG in /usr/share/perl5/PMG/DBTools.pm

[Patrick Fogarty]

One more thing I forgot to mention. The code is failing because, at that 
point, your code wants to know the effective id of the current process. 
It seems to want to the euid to be 'postgres', uid 109 on our machine. 
Unless the code is performing 'su' in some way (I didn't review that 
deeply) that can't happen during an upgrade because apt wants to run as 
root. Also, plain vanilla Debian does not install 'sudo', and we don't 
install it for something like PMG. So the process is not a momentary 
elevation of privilege from a regular user. It is running as root.

Thank you.


Thomas Lamprecht wrote on 4/12/19 11:23 AM:
> Hi,
>
> On 4/12/19 4:17 PM, Patrick Fogarty wrote:
>> If you follow this thread...
>> https://forum.proxmox.com/threads/setuid-postgres-114-failed-inappropriate-ioctl-for-device.41414/
>>
>> ...you will find that I had an issue, as did others, performing upgrades/updates. I adjusted my code manually and things went back to normal. Last month you released PMG 5.2. The upgrade downloads a package that includes the original code, so the upgrade overwrites my changes, then fails the upgrade process "pmg-api --configure", after which I believe the process is in an incomplete state.
>>
>> How can I assist, beyond my post in the above thread, showing the code change I made?
> Either, you could sent a patch here, for this see:
> https://pve.proxmox.com/wiki/Developer_Documentation
> (while written for PVE, almost all is valid for PMG too)
>
> Else you normally also can make a Bug report, which does not gets as easily forgotten as
> some Forum/Mailing list thread: https://bugzilla.proxmox.com/enter_bug.cgi
>
> But posting here may be enough this time, Stoiko, could you please take a look
> at the proposed change:
> https://forum.proxmox.com/threads/setuid-postgres-114-failed-inappropriate-ioctl-for-device.41414/#post-233016
>
> Looking at perl's source code at the Perl_magic_set case for EUID (case '>')
> we just see that there's no special error handling, thus the recommendation
> to check $! (errno or sys_errlist[errno] depending on context) after the call.
>
> We do that, and it seems correct, so either we need to reset it to 0 befor the
> seteuid call to ensure we do not check an old value or this is correct an the
> seteuid really fails in the posted case..
>
> Patrick, can you post a bit more details about your setup, you said you run it in
> PVE, inside a Virtual Machine (VM) or Container (CT)?
>
> Because your change could just omit error checking completely, and thus not be
> the "correct" solution here..
>
> cheers,
> Thomas
>
>