Enable certain control panel options for some users

[sparek]

If I want to prevent users from accessing the Two Factor Authentication portion in their control panel, I can add CMD_TWOSTEP_AUTH to the never_commands in /usr/local/directadmin/conf/directadmin.conf

But what if I want one or a subset of users to have access to this?

Two factor authentication is just an example here - I'd really like to know for most every option in the control panel.

Another words, default deny options for all users and enable certain options on a case by case basis.

Is there a never_commands equivalent that can be used in /usr/local/directadmin/data/users/${username}/user.conf - where you could set this to a default set in a post user create hook, but then remove on a case by case basis?

 

[sparek]

I suppose ONE solution would be to not use never_commands in /usr/local/directadmin/conf/directadmin.conf

But instead use a post user create hook to create a /usr/local/directadmin/data/users/${username}/commands.deny file with the CMD_* you want disabled each on a separate line.

Then if you want that user to have access to Two Factor Authentication, you would simply remove CMD_TWOSTEP_AUTH from that user's /usr/local/directadmin/data/users/${username}/commands.deny file.

That would be ONE solution - but I'm not sure if it's the BEST solution.

 

[zEitEr]

Hello,

In case you need to disable a feature on per user or hosting package bases, and directadmin does not allow disabling it, here is a possible way to go:

- use https://www.directadmin.com/features.php?id=586 and create custom items in user packages.
- use POST/PRE scripts to check the value of the custom item and block an access to a feature whenever it's required.

Probably not very simple, but still a valid solution.

 

[sparek]

Ah! Yes... the patented DirectAdmin documentation.

I'm sure that to the person that wrote that - it made perfect sense. And it might've made more sense to more people if whatever feature that is referring to had recently been discussed. But from an outside observer that reads the words in that link, it's clear as mud. I don't even know what it's referring to.

I think I'll just use the basis of creating a /usr/local/directadmin/data/users/${username}/commands.deny file with the desired disabled options in a post user create hook is the way I'll go. I'll probably expand on it by creating my own system where I can define a "default" set of disabled commands and enable certain commands for certain users with the ability to recreate all commands.deny files for all users on command. That seems to be the best option.

Additionally, I believe I can remove some of these options by making changes to /usr/local/directadmin/data/users/admin/skin_customizations/evolution/files/menu-v2.json - presumably one would have to exist for each reseller. But I actually think the commands.deny file is probably the better solution.

 

[zEitEr]

Ah! Yes... the patented DirectAdmin documentation.

I should have posted this link: https://www.directadmin.com/features.php?id=479 as it gives more details and is more readable (though a page by the previous link contains it as well).

The feature can be used with your way too. Just in case you want to change a list of disabled commands depending on user.conf.

Sure, you are welcome to use anything you might want.