File Manager 22.2 Security & Privacy Manual

Contents > Chapter 3

Chapter 3: File Access-by-User

If your system is running Kernel, your organization has the option of replacing Fileman Access Codes with the Kernel-based File Access-by-User. As we have already discussed, File Access-by-User replaces Fileman Access Codes only for files; field and template access is not overridden.

Technically, File Access-by-User is managed through the Kernel package, not the Fileman package. So technically, we should be sending you to the Kernel documentation suite to learn how to use it. However, File Access-by-User is an important tool in Fileman security, so we are giving you a basic overview of how it works. If you would like to learn more than what we have here, please consult the Kernel documentation.

Granting Users Access to Files

You can grant file access to users in the File Access Security submenu of the User Management option in Kernel.

Select Systems Manager Menu Option: USER Management
Select User Management Option: FILE Access Security
Select File Access Security Option: ?
Grant Users' Access to a Set of Files
Copy One User's File Access to Others
Single file add/delete for a user
Inquiry to a User's File Access
List Access to Files by File number
Print Users Files
Delete Users' Access to a Set of Files
Remove All Access from a Single User
Take away All access to a File
Assign/Delete a File Range
Select File Access Security Option:

Yikes! That’s a lot of options. Fortunately, we can group them into categories that make it easier to remember what they do.

Three of the options deal with listing permissions—that is, with just looking at what kind of access people have. These options are: Inquiry to a User’s File Access, List Access to Files by File Number, and Print Users Files.

Three options deal with editing permissions. These options are: Grant Users’ Access to a Set of Files, Copy One User’s File Access to Others, and Single File Add/Delete for a User. Most sites begin by using the Grant option, but as more users are set up, the Copy option becomes a better choice. You can select a few “model” users whose permissions are appropriate for a certain job category, then just copy their permissions any time you add an employee to that job category.

Three options deal with restricting or removing permissions. These options are: Delete Users’ Access to a Set of Files, Remove All Access from a Single User, and Take Away All Access to a File.

The only option left on the list is the weird one. Strictly speaking, it probably doesn’t belong on this menu, although it would be difficult to say where it would belong. You can use the Assign/Delete a File Range option to give a user a limited ability to create new files. You do this by assigning the user a range of file numbers they can use—obviously, choosing file numbers that are not in use and not likely to be used anytime soon. This option does have security implications; if the user already has read access to a confidential file, they could create a new file, and copy confidential information into it.

For more information about how to use each of these options, please consult the Kernel documentation suite.

In File Access-by-User, each of the six access levels of a file (read, write, LAYGO, delete, audit, and data-dictionary) is associated with a YES or NO in the user’s profile. As we mentioned in Chapter 1, the default is a NO. That is, no users have access to any files unless that access has been granted by somebody.

As with Fileman Access Codes, the access levels in File Access-by-User do not “contain” the lower levels of access. If a user has write access to a file, they will also need to be given read access, or they won’t be able to look at the file they can edit!


Some facilities and organizations who have switched over to File Access-by-User seem to be assuming that Fileman Access Codes are no longer needed. They have stopped giving their users Fileman Access Codes, even though those codes may be needed to access certain fields and templates.

Worse (from a security standpoint), they have begun removing Fileman Access Codes from files. This doesn’t affect them; they still have File Access-by-User to control access to the files. If they share these files, however, or distribute them as part of a patch, then they are sending completely unsecured files to organizations that may not have File Access-by-User in place.

This is a dangerous practice, and we recommend that it stop. We recommend that you, as a Security officer, do what you can to ensure that Fileman Access Codes remain in place. They are single characters; they use almost no computer memory; and they’re not hurting anything by being there. And some people still need them!