If it's large (possibly growing?) set of components, where each component basically has to be set up for a small set of "standard" permission flags, then I should think that the perl coding best suited to this situation would be a hash, with compenent name as the hash key, and a string (e.g. "rwx" vs. "rw-" vs. "r--", etc) representing the basic permissions assigned to a given user for the given component. If you render this as an object class, it would be even easier and more maintainable.

As for storing the hash to a database (and reading it back), there are lots of ways to do this, but perhaps the most practical would be a table entirely devoted to storing permissions: each row would hold "username", "componentname", and "permstring"; the "username, componentname" tuple would serve as a primary key (two components can't have the same name, and one user can't have two different permission settings for the same component).

With such a table, you can "select * where componentname='X'" and see all the users and their permissions associated with that component, or "select * where username='Y'" and see all the components this person is registered for, and what his/her permissions are for each one.

Maybe you want the permission information to be "global" in some way (all contained in one hash, accessible to all components), or maybe it should be set up so that only the database keeps the "global" picture, and each component only fetches and holds the permission data it needs. With a simple permissions table and an object class to manage it, you could go either way. You're also free to choose where to implement dependencies (e.g. users who can do X should all be able to do Y), though it will probably be best to handle this in the components, or in the code that glues components together -- keep the permissions object simple and general-purpose, rather than cluttering it up with stuff that is based on knowledge about what the components actually do.

(Of course, some dependencies are generic no-brainers, like "if you can execute this, you have to be able to read it"; this sort of thing belongs in a "Perms" module.)

update: This train of thought could just lead to a heavier reliance on the database, querying the permissions table whenever something needs to be checked rather than maintaining a perl-internal hash; in that case, you would probably want the different types of permissions (read, write, execute, etc) as separate columns in the table, to allow more efficent indexing and fetches. A "Perms" module would still be useful, to help integrate/migrate the table data for components and users. Keep in mind that it's easy to add columns to an existing table, in case you come up with new types of permissions later on.