Pipe.php permissions get reset on update

[SamS1]

Hi,

Every time we update Whmcs, the permissions for the pipe.php file get reset to 644 from 755. We've had to manually change this for the last few updates once we noticed our piping wasn't working.

There may be user who won't even notice their piping isn't working anymore. Are we supposed to manually update the permissions on every update?

Thanks

Edited September 24, 2019 by SamS1

[bear]

PHP files should not need to run with 755, as it's much less secure. What is it about your environment that needs that?

[SamS1]

The pipe.php requires it to function correctly.

https://docs.whmcs.com/Email_Piping

Edited September 24, 2019 by SamS1

[bear]

My apologies, I'm not using that and didn't nkow

8 hours ago, SamS1 said:

The pipe.php requires it to function correctly.

https://docs.whmcs.com/Email_Piping

The docs say it, but that doesn't mean it's right for every server. We're using pipe, the file is 644, owned by the account user, stored above root so no public access. Works perfectly. 😉

[SamS1]

Ours is also above root also but only works with 755. Emails bounce back with denied with 644.

[Znuff]

On 24/09/2019 at 6:54 PM, bear said:

PHP files should not need to run with 755, as it's much less secure. What is it about your environment that needs that?

This is a very "faux" sense of security.

If an attacker has access to your `pipe.php` somehow, be sure that he can already set 755 on the file. There is absolutely no security risk from having 755 vs 644; the only difference between the two is that 755 also has eXecute rights compared to 644. There would have been an issue if it had `777` or `666` as that would make it world/group writeable/executable.

tl;dr - leave the file's permissions like that

[bear]

1 minute ago, Znuff said:

This is a very "faux" sense of security.

If an attacker has access to your `pipe.php` somehow, be sure that he can already set 755 on the file.

I'm afraid you misunderstand or just didn't get what was being said. 
You don't need root/owner "access" to a file to do something unexpected with it, and you don't need to change permissions to do it, if it already has promiscuous permissions set on it. Though 755 isn't as bad as 777, files/folder should be at the lowest access possible as long as it will keep working. Setting overly "friendly" permissions is lazy, and not a good practice. 😉 

[Znuff]

Just now, bear said:

I'm afraid you misunderstand or just didn't get what was being said. 
You don't need root/owner "access" to a file to do something unexpected with it, and you don't need to change permissions to do it, if it already has promiscuous permissions set on it. Though 755 isn't as bad as 777, files/folder should be at the lowest access possible as long as it will keep working. Setting overly "friendly" permissions is lazy, and not a good practice. 😉 

You are literally not understanding the bits in the permission system.

755 is not "friendly" in any way. the extra bit away from 644 is simply the execute bit.