Browse Prior Art Database

Individual control of routine execution permissions and variable read-write permissions using asymmetric-encryption key pairs Disclosure Number: IPCOM000125914D
Original Publication Date: 2005-Jun-22
Included in the Prior Art Database: 2005-Jun-22
Document File: 5 page(s) / 52K

Publishing Venue



Disclosed is a method for managing permission for software execution at the routine level, and read/write access to program variables using asymmetric-encryption key pairs. A public key is inserted into the program source code and associated to functions or variables. The public key as well as the code to test whether the user has the associated private key are compiled into the final executable. At runtime, if the user has the correct public key, he/she will be able to execute a protected function or to read/write to a variable.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 16% of the total text.

Page 1 of 5

Individual control of routine execution permissions and variable read -write permissions using asymmetric-encryption key pairs

Main Idea


The vast majority of computing systems today are shared by many users, be they large corporate servers on the internet or small workstations on private networks. Finding secure but yet flexible ways to grant and control the access of the computing resources by different users is a core issue in system development and administration. Among the resources that have to be controlled are the permissions to execute certain programs or pieces of code by users.

The traditional way to manage execution permission is at the binary-executable level. On Unix-like systems, for instance, each file has a permission mask that includes the permission or denial for a given user to execute that program. For example, the executable named "rscsi" and located at "/usr/sbin/rscsi" will have the following properties:

-rwxr-xr-x 1 root cdwriter 79988 jan 27 08:28 rscsi

The first group of characters defines the permission mask of the file. It starts with a dash, which means it is a regular file, followed by three groups of three characters: "rwx", "r-x", and "r-x". The first three characters give the permissions granted to the owner of the file, that is "root" in that case. The "r" flag means that the root user can read that file; the "w" flag means he/she has write access to the file; and the "x" flag says that the root user may execute the file. The second set of three characters describes in the same way the permissions granted to the group "cdwriter", to which the root user belongs. The "-" flag instead of a "w" flag means that other users in the "cdwriter" group do not have write access to the file. On the other hand, they are granted read and execution access for that file. The last set of flags reflects the permissions granted to all other users - those that are neither the root user nor in the "cdwriter" group.

Managing execution permissions with a permission mask is sufficient in most cases. For more demanding cases, other access-control schemes have been defined, like the POSIX 1003.1e draft 17 ACLs (Access Control Lists,, which makes it possible to set access permissions for other individual users, to create new groups and grant them read/write/execute priviledges.

In terms of execution permission, the problem with this approach is that it is a all-or-nothing property: if a user is granted execution permission on one executable, he/she has executation permissions for all executable code in the executable file. This is not always desirable and techniques were invented to have a finer control over execution permissions by individuals.

One way to solve the issue would be to split the executables into pieces, assign execution permissions to each piece, and the pieces would "call" each other when needed. If a user is not allowed to run one piece of the softwar...