• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Resolved Can subscription users run scheduled tasks as root?

Bitpalast

Plesk addicted!
Plesk Guru
On https://docs.plesk.com/en-US/17.0/a...-guide-linux/enhancing-security.68755/#o68759 it is said, that "By default, Plesk allows utilities or scripts to be run on behalf of root in two cases: Scheduling tasks with the cron manager ...".

When we create a scheduled task from within a subscription, how can this be run under root? By default it is created to run as the subscription at least it looks like it. Is there a vulnerability we are unaware of, e.g. can a subscription user create a scheduled task that runs with root permissions?
 
In general, the situation is following - Plesk uses a username - psaadm, and there is no prohibition to set psaadm synonymous of root - i.e. set up uid to 0.
Event handler tool - is mechanism for launch event handler occurring in the business logic for the extensions, i.e, an event "domain creation" occurs - the business logic runs handlers for extensions with this event. In fact additional sw-engine process runs under the user psaadm. It is possible that psaadm is synonymous of root - and for preventing the creation of such processes, you can create a file $PRODUCT_ROOT_D/var/root.event_handler.lock

Regarding $PRODUCT_ROOT_D/var/root.crontab.lock file - the point is that the admin user can create tasks for the root user.
In other words by default admin can do it, if you create this file - admin can't do it.
 
Hi @IgorG ,

I had same Question today, im not sure about this. Didn't understand fully....

So if I implement "$PRODUCT_ROOT_D/var/root.crontab.lock file" it will

1. block normal users and or stupid hackers to create Root task. (very good)
2. block me as root/ admin to create NEW Crons? (hm.....)
3. wont harm any existing cron jobs which was set up via root? and or wont disturb any Cronjobs from Plesk etc.?

Am I right?
 
Am I right?
Yes, generally you are correct.
There are the following cases when Plesk admin can run arbitrary code with root privileges:
  1. Scheduled Tasks with root system user (can be eliminate by /usr/local/psa/var/root.crontab.lock).
  2. Event Handlers with root system user (can be eliminate by /usr/local/psa/var/root.event.handler.lock).
  3. Upload Extension (cannot be eliminated at the moment, as I far as know).
There are some specific scenarios described in already existing report PPP-28512 which will be considered and resolved in the next Plesk version.
 
HI @IgorG ,

thank you, i am a little confused.
i created those files and can't see any of my .... 20-30 Cronjobs in PLesk GUI. Is this correct?
Is this right?
Should i undo my changes?
I ran
Code:
# touch /opt/psa/var/root.crontab.lock
# touch /opt/psa/var/root.event.handler.lock
 
Last edited:
Back
Top