There's a "old" feature in DNN that allows module developers to create their own custom permissions for the modules they are creating. This will allow you to create a module and specify more granular permissions than the default VIEW / EDIT options DotNetNuke provides by default.

Yet a very powerfull feature I've seen this option not being much used. Actually very few module use that.
Why? I think the reason is because of a lack of documentation and examples from DNN core modules itself (an exceptional exception is the UDT module, from which I based some of this code). So I thought it would be good idea to provide some explanation on this and a piece of sample code for everybody to use.

What do we want
The overall goal of this exercise is to create some custom permissions for a module so it can have other options than the VIEW / EDIT default permissions. For example, decide which roles will be able to edit a specific item in the module.
The new permissions for the module will appear *automatically* on the permission grid in the module settings page without any extra step on your (the developer) part.

Structure
DotNetNuke provides two tables that support this feature. First there is the Permission table where all permissions are defined

and then we have the ModulePermission table where permission for each module are stored.

Note that this table contains not just module related permissions but all permission types (including folder and tabs). If at any given time DNN supports more granular permissions for these objects you will see them defined here.

On the Modules side note that the default permissions are defined with a code of "SYSTEM_MODULE_DEFINITION".
So the first thing to do when creating custom permissions is decide a unique code for your module. I suggest you use something similar to "MODULE_YOURMODULENAME".
ModuleDefId is a reference to the module that "owns" the permissions and PermissionKey, PermissionName define every permission you want to add.

Setup
A small problem with the current solution is that DNN does not provide any automated way to install new permission definitions when a module is installed. I'm sure we will solve this in a future version.

So we'll have to create some code to handle this, and the best way of doing it is by implementing the core IUpgrade interface. This interface defines a method that will be called everytime a new version of the module is installed, even the first version. So just add this piece of code to your controller class to handle the setup of module permissions:

Note that this code references a class named ModuleSecurity, more on this in a moment.

At this point, when you enter the module settings page for any module of this kind you will see the custom permissions on the permission grid.

and this is how the permission table data should look now.

Use
At this point we have all the infrastructe ready to start using these permissions on our custom module.
Here is a sample class the encapsulates then common needs.
- it defines the permissions definition constants (used in all access to the data)

Now you can use that class on your module's code and do something like that:

Conclusion
You can see that without much effort you can provide a much richer configuration interface to your module configuration using builtin DNN capabilities, and take advantage of the gread security features the framework has right out of the box.