different plugins for different unprivileged users w/ one install?

PeterJones

Why is the allowAppDataPlugins.xml solution no longer available?

The developers thought it was too much of a security risk (bad actor could easily replace the plugin with code that would do something nefarious). It’s no more insecure than a normal portable installation, but it definitely protects systems that have a central installed location.

Neither of those solutions allow the admin to set/update the version of NPP while keeping user-selected plugins personal.

Unless you do more work in the setup of the installation or portable.

You could, for example, create a portable edition for each user, but change the permissions on notepad++.exe and its support DLL so that they cannot overwrite the executable (and thus not update for themselves), but let them have permissions to write to the various portable config files and plugins directory.

Or you could have the plugins directory be a Windows Junction or Symbolic Link to a user-specfic directory, and when they log in, a script/program/batch-file sets that Junction to point to their directory. If that doesn’t make sense to you, then maybe this sequence will help you see what I’m suggesting:

Do normal installation to C:\Program Files\Notepad++\
Change permissions on the C:\Program Files\Notepad++\Plugins so that it can be deleted

On user login (using Task Scheduler or whatever startup scripts you already have your users running), run the following commands:

IF EXISTS "C:\Program Files\Notepad++\Plugins" RD "C:\Program Files\Notepad++\Plugins"
MKLINK /J "C:\Program Files\Notepad++\Plugins" "%AppData%\UserNppPlugins"

Or similar to that: instead of making it a junction, on each login, empty out the Plugins directory and copy over the contents from their %AppData%\UserNppPlugins into C:\Program Files\Notepad++\Plugins – it might be easier to set up permissions so that the things inside Plugins\ can be removed/added without having to give permissions for the Plugins directory (or junction) itself to be deleted and re-junctioned each login.

These are just off-the-cuff ideas; I haven’t tested any of them. If they don’t work for you, maybe they’ll be springboards for other paths which might lead you to a solution.

gstavi

@teknowledgist
I can’t help you with the question, as I don’t follow Notepad++ closely enough, but I do want to focus your attention about a security issue.
Having Notepad++ load DLLs from user directories is a security risk. Gaining disk write privileges’ to user area and putting code there is relatively easy. Causing the user to run this code is somewhat trickier. If this code sits in Notepad++ plugin DLL it becomes a penetration vector. Having the admin control Notepad++ installation becomes rather irrelevant. If you trust your users feel free to go with the fully portable version per-user solution.

A feature you may want is to have Notepad++ the ability to enable/disable plugins per-user based on configuration from user directories. All the DLLs will be installed in program files by admin but each user could select the plugins to enable.

teknowledgist

@gstavi
If there were a way for admins to effectively provide a library of optional plugins for users, that would be fantastic! Admins could review and deploy plugins that they trust/approve, and users could enabled those approved plugins within their use of NPP as they want/need.

Unfortunately, I don’t expect this will happen anytime soon.

gstavi

@teknowledgist
Make a feature request in Notepad++ project page

Technically it should not be very complicated.
Notepad++ during its startup scans for plugins and starts them. I am not sure if it is just a scan of “plugins” directory or if some configuration file is used.

Adding a pre-stage where Notepad++ reads a user configuration file (plugins.user.xml) that contains a list of plugins to skip should be easy enough.

mkupper

@gstavi
It seems that Notepad++ used to allow for both user and system plugins much like how you are proposing. Unfortunately, I can’t recall where on the Internet this is explained clearly as to how various historical versions of Notepad++ figured out which plugins to load. I do recall there was no explanation on that web page of why Notepad++ was changed.

Coises

@mkupper said in different plugins for different unprivileged users w/ one install?:

@gstavi
It seems that Notepad++ used to allow for both user and system plugins much like how you are proposing. Unfortunately, I can’t recall where on the Internet this is explained clearly as to how various historical versions of Notepad++ figured out which plugins to load. I do recall there was no explanation on that web page of why Notepad++ was changed.

See https://community.notepad-plus-plus.org/topic/16645/new-plugins-home-where-notepad-will-load-from/ and https://community.notepad-plus-plus.org/topic/16996/new-plugins-home-round-2

Have the Excedrin ready. :-(

gstavi

@mkupper said in different plugins for different unprivileged users w/ one install?:

It seems that Notepad++ used to allow for both user and system plugins

As I said in my first post here. Loading plugins (DLLs) from user folders is a security risk.
This proposal is different. Plugins are only loaded from administrator controlled folder (Program Files) but user can choose to avoid loading plugins he does not like.

Coises

@gstavi said in different plugins for different unprivileged users w/ one install?:

Plugins are only loaded from administrator controlled folder (Program Files) but user can choose to avoid loading plugins he does not like.

If this were to be done, it seems to me the sensible way would be to modify the Plugins Admin interface for ordinary users so it would show only the Available and Installed tabs, omitting the Update and Incompatible tabs. The list in Available would be limited to plugins already installed at the system level by an administrator, and Installed would show the plugins the user has enabled. That way the interface for non-administrative users in a controlled environment wouldn’t be all that different from the one for users who have control of their own machines. In my opinion, ordinary users should not be confronted with obscure configuration files.

Perhaps a simple way to control this would be the presence of any file (even an empty one) at %AppData%\Notepad++\plugins\enabled.xml. So long as that file is present, the “unprivileged user” interface is presented. (It doesn’t matter that a user could delete that file, because they still wouldn’t be able to install, remove or update plugins. They’d just have given themselves access to an interface that is useless to them.) So long as it’s not a problem to create an empty copy of that file for each new user (and one time, on introduction of the feature, for existing users), I think that would work. Administrators could get access to the full interface by temporarily renaming that file.

Whether there is enough desire for something like this to make a convincing case for that big a change is another question.

gstavi

@Coises
“Sensible” is such a personal concept.

Think of the plugin domain as 2 different layers:

Install/uninstall
Enable / disable -or- use / don’t use

The 2 concepts do not have to share a GUI. I will argue that separate administrative interface is better then unified interface that its features magically change.
Current plugin admin IS the administrative interface.
The 2nd interface is missing.

Today the layers are coupled, install=enable, disable=uninstall. You would want to maintain this property for backward compatibility since 99% of user want it that way.

Technically the only needed feature is disable. Any plugin that is not disabled is enabled by default. An enable/disable GUI can be designed to show all non-disabled plugins as enabled since this will be less confusing to users.

Coises

@gstavi said in different plugins for different unprivileged users w/ one install?:

Technically the only needed feature is disable. Any plugin that is not disabled is enabled by default. An enable/disable GUI can be designed to show all non-disabled plugins as enabled since this will be less confusing to users.

I agree that there are some advantages to the approach you suggest compared to what I proposed. While I feel that presenting an interface (Plugins Admin) to users which they cannot use isn’t ideal, locked-down users are probably used to that; and there would be a significant advantage of simplicity and predictability in not having Notepad++ behave differently depending on the presence or absence of an obscure file, as in my suggestion. And I can see how any user, including the typical single user with administrative rights, might sometimes want to disable a plugin without uninstalling it, so that would be an added feature.

I do see a problem with “the only feature needed is disable.” In the multiple users situation, when an administrator adds a new plugin at the request of one user, it will appear, probably unexpectedly, for every user until each user who does not want it disables it. I think the internal list should be a list of enabled plugins, not disabled plugins, to avoid unexpected behavior.

I think it would work if installing a plugin automatically added it to the list of enabled plugins for the user installing it. That would keep the expected behavior for both single users and multiple users.

Aside from whether to keep a list of enabled or disabled plugins, I think I agree that your solution is better than mine.

Would you make Enabled a new tab on Plugins Admin, or a whole new dialog?

Edit to add:

It seems like it belongs on the Installed tab, but I’m having a bit of trouble envisioning how it could be added without making the tab confusing. A question would be whether it would be necessary to restart Notepad++ to enable or disable plugins — it would be better if not, but I don’t know if that could leave some inconsistencies. The answer to that would affect the UI: we would want a clear confirmation button, like the existing Install/Update/Remove, if a restart is required, but simply toggling checkboxes would work if the new configuration can be applied on closing the dialog without a restart.

And over all of this is whether anyone is up for developing the pull request, and whether Don would accept it if they did.

teknowledgist

I don’t mean to make this more complicated, but from an educator/sysadmin point of view, it would be handy to be able to:

force some plugins to be enabled
set some plugins to be enabled by default but disable-able by users
make some plugins disabled by default but enable-able by users.

However, I would be happy with only the enabled by default option. That would keep functionality closest to what it is for single users while allowing admins to deploy plugins.

teknowledgist

Feature Request made