Issue New FTP user becomes owner of all files of the webspace

[Felix]

Server operating system version

AlmaLinux 8.7 (Stone Smilodon)

Plesk version and microupdate number

Plesk Obsidian v18.0.47_build1800221020.08 os_RedHat el8

Not sure if this is a bug or a feature, but it feels wrong.

I am in the progress to migrate to a new server that runs Plesk Obsidian 18.0.47.
I have a system user on a domain called user1.
All files of the domain and subdomain are owned by this user. This is good.
I now add a new FTP user (user2) that should only be able to access a certain folder on the domain. So I set its home directory to this folder.
When I save the user, ALL files of the complete domain are now owned by user2.
Furthermore, I am not more able to switch the permission back when setting the system user back to user1 (as it still seems to be user1).
When trying to change the system user to something different, say user3, I get an error message (that I dont remember now).
When I now reboot the server, I can set the system user to user3, and right afterwards back to user1 and all permissions are back to normal.
And user2 still has access to the folder for which it was created.

Hope the steps are clear to reproduce it.

It really feels like a bug, especially because a reboot is necessary to fix it. Let me know if there are any more information necessary or if I should file a bug report.

Best,
Felix

 

[Kaspar]

I don't think that's suppose to happen. However I am unable to reproduce the issue on my server. For me the domains system user remains to owner of all files and directories. Including the home directory set for additional FTP users. So this might be an issue specific to your server?

Best advice I can give is to open a support ticket with Plesk so they can investigate the issue directly on your server.

How to get support directly from Plesk?

Question How to get support directly from Plesk? Answer Lease-type Plesk licenses purchased directly from Plesk running on supported Plesk version include full free support. Perpetual-type license...

support.plesk.com

 

[Bitpalast]

When trying to change the system user to something different, say user3, I get an error message (that I dont remember now).
When I now reboot the server, I can set the system user to user3, and right afterwards back to user1 and all permissions are back to normal.

The error message that you might have seen is related to updating a user account that is currently owning a process. While there are processes running on that account, it is not possible to change the account. When you reboot the server, the user for sure does not execute anything, that is why you can then do the update. To update a user account without the need to reboot, simply set the web space to "deactivated". This will halt all such processes. You can immediately proceed with user acount changes. Once you are done, switch the web space back to "active".

Regarding the additional FTP user and the account user: The (system) account user has FTP privileges, but it is much more than just some FTP user. An FTP user however has only FTP privileges. Adding an FTP user will not change the ownership of files other than the ones that descend from the FTP user's home directory. I think what you could check is whether the FTP home directory was set correctly. When you set it to "/" (your system user's root) and then do FTP transactions on that directory, sure new files or updated files will be owned by the FTP user. Like @Kaspar I cannot confirm a bug, but if you can reproduce the issue, it would be kind if you could please file a report here:

Reports

Please, click Post New Thread button and fill the form if you really believe you discovered a new bug and need to report it to the Plesk developers. It does allow us to handle and resolve your requests much more efficiently. Please be careful and do not submit any found problem with this...

talk.plesk.com

 

[mow]

This might be just a cosmetic issue. When Plesk adds more users to a domain, they all have the same user and group id (so they each can access the same files without permission/owner problems). Such users still have separate entries for home directory, shell (/bin/false for ftp-only users) and password in /etc/passwd resp /etc/shadow.

 

[Felix]

Hei there.
Thanks @Peter Debik and @Kaspar for the super quick reply! Thanks as well to @mow for chipping in.

The error message that you might have seen is related to updating a user account that is currently owning a process. While there are processes running on that account, it is not possible to change the account. When you reboot the server, the user for sure does not execute anything, that is why you can then do the update. To update a user account without the need to reboot, simply set the web space to "deactivated". This will halt all such processes. You can immediately proceed with user acount changes. Once you are done, switch the web space back to "active".

Sounds pretty much right. I kinda remember that the error message was about process owning.
I cant test this now, as the server is under full load at the moment.

However, before opening this thread I was able to reproduce this behaviour (in total it happened twice).
I also checked the file permissions via ssh and they really had changed on all webspace files and folders (regarding @mow s comment).
I did not check the permissions of the other folders, like /etc/passwd or alike...

Not sure if this is important, but my setup is one parent domain and several subdomains. The new FTP users home is the home directory of one of the subdomains.

In the next week or so I will setup another server as a backup for this one and it will be configured exactly the same way.
If the same problem happens again, I will let you know and open a report.
Let me know if there is a specific test that you would like me to do, in case I can reproduce the problem.

Best,
Felix

 

[mow]

I also checked the file permissions via ssh and they really had changed on all webspace files and folders (regarding @mow s comment).

Did you check the numeric ids (ls -lan) and cross-check with the user ids (id user1; id user2 ...)?

 

[Felix]

Did you check the numeric ids (ls -lan) and cross-check with the user ids (id user1; id user2 ...)?

No, I did not. Only did

ls -la

. I will try this the next time I encounter this problem.
But even if the ids would be the same, the only thing that is visible in the plesk panel is the user name, so it probably will cause confusion for every other user that encounters this bug/problem...

 

[Felix]

Hei there.
I have now started to setup the second server and the same happened again.
I took some prints, but I am not sure how much they would help...

And I checked the numeric ids, and @mow is right, they stay the same.

Best,
Felix

 

[fabrizioi]

Hi Felix,

I have the exactly some issue .

I use Plesk from version 7 never seen such a thing.

I have many Plesk WebServer with CentOS, this bug is specific with AlmaLinux.

Issue - Strange File Permission View Issue

Hi All, I'm on Plesk Obsidian 18.0.51 with AlmaLinux 8.7 . Everything works fine (this is my first machine with AlmaLinux instead of CentoOS) Consider this scenario: subscription mydomain.com user subscription mydomain.com If i create an additional FTP Account for example subftp-user to a...

talk.plesk.com

 

[Kaspar]

@fabrizioi as @mow stated this is most likely just a cosmetic issue and should not impact functionality.

 

[fabrizioi]

Hi Kaspar,

I can agree.

But for me is not suitable.
As workaround I have removed the three additional ftp user (and I will migrate service related to them to something other than ftp protocol)

I can't work in a shell where I chown mainusersacln and the system tell me that the owner is subusersacln .
Sooner or later I make some trouble.
I understand that it is not easy to fix on the system side otherwise the Plesk Team would have already done it.

Thanks for your support

Regards

Fabrizio

 

[MarkM]

For what it's worth, I can't replicate this on Alma, but I'm running 9.1 already.

Product version: Plesk Obsidian 18.0.52.1
OS version: AlmaLinux 9.1 x86_64
Build date: 2023/04/28 12:00
Revision: e360fb7feaab0cb90c1223f9c8801f854f24ca35

 

[Kaspar]

But for me is not suitable.
As workaround I have removed the three additional ftp user (and I will migrate service related to them to something other than ftp protocol)

I can't work in a shell where I chown mainuser:psacln and the system tell me that the owner is subuser:psacln.
Sooner or later I make some trouble.
[...]

If you put it that way one could argue it's not a cosmetic issue but actually a bug after all. So I encourage to submit a detailed bug report about this issue here, so developers can at least investigate the issue and perhaps solve it. Who knows

 

[fabrizioi]

Hi MarkM,

Sorry for the late in the reply.

I appreciate your feedback .

Thank you.

Bye

Fabrizio

 

[fabrizioi]

Hi Kaspar,

Thanks for the detailed information .

As soon as possible, I'll do it.

Bye

Fabrizio

 

[mow]

Have you tried reordering the entries in /etc/passwd? It should use the first match for a uid ...

 

[Felix]

Hei there.
I just was bitten again by this problem.
And it actually is pretty serious, in my opinion.

We have the main application running via pm2. It runs under one of the ftp users (so it does not have root permissions).
We now have added a new ftp user and this KILLED the pm2 process, running under the other ftp user.

Manually restarting the process under the first user restarts the app but it is now listed under the second ftp users name in the process list.
This would not really be a problem, but is very confusing.

Nevertheless, we have now removed the second FTP user and the pm2 process was again killed.

Luckily, we have been connected via ssh at the time when this happened, but our app was offline for some time even though...

I really feel like this is a problem and should be addressed.

Best,
Felix

 

[Kaspar]

@Felix please submit a detailed bug report about this issue here so developers can investigate the issue.

 

[fabrizioi]

Have you tried reordering the entries in /etc/passwd? It should use the first match for a uid ...

Hi,

Not yet, but if you have read previous post, I believe this is not a solution .
If I try connect to the subscription for example from FileZilla with ftp protocol, it report the real correct permission.
This proves, that is not a problem of account ordering, in my opinion .

Thanks for the help.

Regards

 

[fabrizioi]

@Felix please submit a detailed bug report about this issue here so developers can investigate the issue.

I have reported the issue as advised