Permissions are low-level things - they specify that a user can do exactly A, but not B in a given context. Permissions are used as guards on access to methods, scripts, page templates, workflow transitions and sometimes individual components on a page.

The most common permissions are View, Modify portal content, Access contents information and List folder contents. These (along with a few others, such as Manage portal) are the so-called CMF Core permissions, found in the file Products/CMFCore/CMFCorePermissions.py in variables with names such as View and ModifyPortalContent. In general, most content types use these permissions for accessing and modifying data. You may think that a little strange at first, but you will see later how workflow is used to gain fine-grained control over these permissions.

Permissions are assigned to roles of users, not individual users. So, in folder X, anyone in the RandomRole role can Modify Portal Content. The default roles are Member, Manager and Reviewer. There are also some "automatic" roles - these are Owner and Anonymous. The Anonymous role is inhabited by users who are not logged in. Most portal members have the Member role, but it is not guaranteed. Owner only applies where the current user is the owner of a piece of content.

In the Zope Management Interface, (almost) all objects have a Security tab. Here you will see a (rather large) grid of member roles assigned to permissions. Most of these will be set to Acquire permission settings, which means that the roles given this permission are the same as that of the parent object. Zope security settings are additive, so if you leave the acquire flag checked and select some additional roles, you will get the roles set at the parent level plus any additional roles set at this level. You can stop this acquistion of roles by unchecking the aquire flag.

In most cases, you will not modify permissions in this way, except to set site-wide defaults for permissions other than the core permissions above. One fairly common example is to restrict the Add portal member permission to managers only at the root level to close your portal to public sign-up: by default it is given to the Anonymous role, which means that anyone can join the site (and thus create a new portal member). However, your first point of call should always be the workflow.

You are perfectly at liberty to add new roles where this makes sense. Since members can be in more than one role simultaneously, you probably only need to worry about a subset of the permissions when it comes to assigning permissions to a new role. Use the form at the bottom fo the Security tab at the portal root to add and remove roles.

Users can be assigned to roles manually using the acl_users user folder at the root of your Plone instance (not the one at the Zope root). However, it is more common to assign roles to groups and then add users to groups, as described in the next section.