Skip to main content

install_plugin inherits restrictive umask and can create unreadable Jupiter DynamicUI/addonfeature files

Kent Brockman

Hi,

I found a reproducible behavior in cPanel & WHM 136.0 build 35 involving /usr/local/cpanel/scripts/install_plugin.

A plugin installed normally under a standard umask works as expected:

umask 0022

/usr/local/cpanel/scripts/install_plugin \
    /root/cpanel-perm-test \
    --theme=jupiter

The generated files are:

-rw-r--r-- (644) root:root /usr/local/cpanel/base/frontend/jupiter/dynamicui/dynamicui_cpanel_perm_test.conf
-rw-r--r-- (644) root:root /usr/local/cpanel/whostmgr/addonfeatures/cpanel_perm_test

However, using exactly the same clean test plugin under a restrictive umask:

(
    umask 077

    /usr/local/cpanel/scripts/install_plugin \
        /root/cpanel-umask-test \
        --theme=jupiter
)

produces:

-rw------- (600) root:root /usr/local/cpanel/base/frontend/jupiter/dynamicui/dynamicui_cpanel_umask_test.conf
-rw------- (600) root:root /usr/local/cpanel/whostmgr/addonfeatures/cpanel_umask_test

install_plugin still reports:

Plugin installed ok

but the plugin is not available in the cPanel Jupiter UI.

The cPanel user context cannot read the generated metadata.

For example:

uapi --user=CPUSER Features list_features

can fail with:

Permission denied
/usr/local/cpanel/whostmgr/addonfeatures/...

and:

uapi --user=CPUSER Branding get_available_applications

can report:

Failed to read:
/usr/local/cpanel/base/frontend/jupiter/dynamicui/dynamicui_....conf

Changing the affected metadata files from 0600 to 0644 immediately restores the plugin in Jupiter and the UAPI calls return successfully.

I also tested reinstall behavior.

If the DynamicUI/addonfeature files already exist as 0600 and I run install_plugin again, their permissions remain 0600. install_plugin does not normalize the permissions of existing metadata.

I also tested whether the mode of the source install.json mattered.

It does not:

install.json = 0600
umask = 0022

still produces new destination metadata as 0644.

So the reproducible variable is the effective umask of the install_plugin process.

This was initially discovered because several unrelated third-party cPanel plugins disappeared from Jupiter. Some of their addonfeature/DynamicUI metadata had been created as 0600. Normalizing those files to 0644 restored all affected entries.

Is inheriting the caller's umask for these generated cPanel metadata files expected behavior?

Since the generated DynamicUI and addonfeature files must later be readable from a cPanel user context, would it make sense for install_plugin to either:

  • explicitly create/normalize these metadata files with an appropriate readable mode; or

  • detect that the resulting files are unreadable to the cPanel user context and return a warning/error instead of Plugin installed ok?

This is fully reproducible on cPanel & WHM 136.0 build 35.

Thanks.

Marcelo

Comments

5 comments

Date Votes
  • cPRex Jurassic Moderator

    Hey there!  I think the main issue here is the "why" behind the disappearing plugins.  Knowing why that originally happened would be the key to solving this.

    This is also likely something best handled through a ticket so we could see your specific system, as I don't have similar reports of this happening on my end and I doubt this is something specific to version 136 as that plugins area hasn't changed in some time.

    0
  • Kent Brockman

    Thanks for the reply. I think my original post may have jumped too quickly into the technical reproduction and missed the context of why I tested the umask in the first place.

    This started on newly installed cPanel servers running cPanel & WHM 136.0.35 with Jupiter.

    After installing Softaculous 6.3.7, Softaculous itself was working in WHM and the main “Softaculous Apps Installer” entry appeared in cPanel, but the separate Softaculous “Top Apps” section did not appear.

    While troubleshooting that, I also noticed that some unrelated third-party cPanel plugins were missing from Jupiter on the same fresh servers, while others were visible.

    That made me look for something common between the integrations rather than assuming this was only a Softaculous problem.

    I eventually found that the missing integrations had cPanel metadata files created as:

    0600 root:root
    under:
    /usr/local/cpanel/whostmgr/addonfeatures/
/usr/local/cpanel/base/frontend/jupiter/dynamicui/
    while the integrations that were visible had equivalent metadata in:
    0644 root:root
    UAPI confirmed the problem. For a normal cPanel user, calls such as:
    Features::list_features
Branding::get_available_applications
    were failing with Permission denied / Failed to read when they encountered those 0600 metadata files.

    As a test, I changed only the affected generated metadata files from 0600 to 0644.

    Immediately:

    • the Softaculous Top Apps section appeared again;
    • the missing third-party cPanel plugin entries appeared again;
    • the UAPI calls returned successfully.

    So at that point the practical issue was clear: those generated metadata files needed to be readable by the cPanel user context.

    The next question was: why were some of these files ending up as 0600 on fresh installations?

    That is what led me to test install_plugin.

    I created a completely disposable test plugin and installed it using the standard cPanel command:

    /usr/local/cpanel/scripts/install_plugin /root/cpanel-umask-test --theme=jupiter
    With the normal root umask:
    umask 0022
    the generated files were:
    0644 dynamicui_*.conf
0644 addonfeatures/*
    I then fully uninstalled the test plugin and repeated the clean install under:
    (
    umask 077
    /usr/local/cpanel/scripts/install_plugin /root/cpanel-umask-test --theme=jupiter
)
    This time install_plugin created:
    0600 dynamicui_*.conf
0600 addonfeatures/*
    and still reported:
    Plugin installed ok
    but the plugin was no longer usable from the cPanel user context.

    So just to clarify: I was not increasing the umask as a workaround.

    I used umask 077 only as a controlled reproduction after discovering that real plugin metadata on the fresh servers had already ended up as 0600.

    I also tested reinstall behavior: if those metadata files already exist as 0600, running install_plugin again does not normalize them back to 0644. A clean uninstall followed by a fresh install under 0022 recreates them correctly.

    I do not believe this is related to modifying RPM-managed files. The files I am referring to are plugin metadata generated by install_plugin itself.

    For our own plugins, we have now made the installer defensive by:

    • running only the install_plugin registration step under umask 022;
    • explicitly normalizing our own generated cPanel metadata to root:root 0644;
    • repairing historical 0600 metadata during upgrades.

    We have deployed that across our servers and the affected integrations are working normally again.

    What I am trying to understand from the cPanel side is:

    Is it expected that install_plugin may create DynamicUI/addonfeature metadata as 0600 when called from a process with a restrictive umask, even though those files later need to be readable from the cPanel user context?

    If that behavior is intentional, perhaps the required umask should be documented for plugin installers.

    If not, perhaps install_plugin should normalize the permissions of the metadata it creates, or at least warn when it finishes successfully but the resulting metadata is not readable by the cPanel user context.

    Thanks! :-)

    0
  • cPRex Jurassic Moderator

    Thanks for the additional details - that's exactly what I needed to know!

    I've reached out to our developers and had them create case CPANEL-56170, "/scripts/install_plugin doesn't enforce umask on metadata write."

    This will essentially force the install_plugin tool to use the correct value umask at all times moving forward, which will keep this issue from happening.

    I think the ultimate solution until that is in place would be to reach out to Softaculous to see if they can adjust things on their end so it installs with the proper permissions, but eventually this should get taken care of by us.

    0
  • Kent Brockman

    Thank you very much! Glad I could help.

    0
  • cPRex Jurassic Moderator

    For sure - thanks for pointing this out!

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post