# Full Access Permission Lists
LLMS index: [llms.txt](/llms.txt)
---
-
Target Database:
—
-
Context Type:
—
-
Alert Severity:
—
-
Triggered Time:
—
-
Firing Context:
—
## Full Access Permission Lists Report
**Report ID:** `security-full-access-permlists`
**Category:** Security
**Default Parameter:** `minMenuCount = 50`
## Purpose
This report identifies PeopleSoft permission lists that have an unusually high number of menu authorizations. Permission lists with 50+ menu authorizations are usually "superuser" lists that grew organically. Find them so you can audit who has them.
## What It Detects
Permission lists where the total count of menu authorizations meets or exceeds a configurable threshold (default: 50).
Menu authorizations are entries in `PSAUTHITEM` that match real menus in `PSMENUITEM` via a parent-child join. This excludes special permissions like APPLICATION_DESIGNER, DATA_MOVER, QUERY, and WEBLIB entries.
## Tables Queried
### PSCLASSDEFN — Permission List Definitions
The primary record for PeopleSoft permission lists (also called "classes").
| Field | Description |
| ------------- | ----------------------------------------------- |
| CLASSID | Permission list name (primary key) |
| CLASSDEFNDESC | Description of the permission list |
| LASTUPDOPRID | Last operator who modified this permission list |
| LASTUPDDTTM | Timestamp of last modification |
### PSAUTHITEM — Menu Authorization Entries
Each row represents a menu/bar/item combination that a permission list is authorized to access.
| Field | Description |
| ----------------- | -------------------------------------------- |
| CLASSID | Permission list (foreign key to PSCLASSDEFN) |
| MENUNAME | Menu name |
| BARNAME | Menu bar name |
| BARITEMNAME | Menu bar item name |
| DISPLAYONLY | Whether access is display-only |
| AUTHORIZEDACTIONS | Bitmask of authorized actions |
### PSMENUITEM — Menu Item Details
Used via a parent-child join with PSAUTHITEM to validate that authorization entries correspond to real menu items. Only PSAUTHITEM entries matching a PSMENUITEM record are counted.
| Field | Description |
| ---------- | -------------------------------- |
| MENUNAME | Menu name (join key) |
| BARNAME | Menu bar name (join key) |
| ITEMNAME | Item name (joins to BARITEMNAME) |
| PNLGRPNAME | Component name |
| MARKET | Market code |
| ITEMLABEL | Display label |
## Data Flow
```text
1. Fetch ALL permission lists from PSCLASSDEFN
via SearchPermissionLists (batches of 300)
|
v
2. For EACH permission list:
Query PSAUTHITEM joined with PSMENUITEM
via GetMenuAuthorizations (pages of 100)
Count total matching entries
|
v
3. Filter: keep only permission lists where
menu auth count >= minMenuCount (default 50)
|
v
4. Sort results by menu auth count (descending)
|
v
5. Generate Markdown report with summary table
```
## Report Output
The generated report contains:
- **Header** with database name, generation timestamp, and threshold value
- **Summary** showing total permission lists analyzed and count flagged
- **Flagged Permission Lists table** with columns:
- Permission List (CLASSID)
- Description (truncated to 50 characters)
- Menu Auth Count
- Last Updated By (operator ID)
- Last Updated (timestamp)
- **Recommendations** section with remediation guidance
## Parameters
| Parameter | Default | Description |
| -------------- | ------- | --------------------------------------------------------------- |
| `minMenuCount` | `50` | Minimum number of menu authorizations to flag a permission list |
## Interpreting Results
- **High counts (200+):** These permission lists likely grant access to a very large portion of the application. They are often "admin" or "superuser" lists and should be reviewed to ensure they are only assigned to appropriate roles.
- **Moderate counts (50-200):** May indicate permission lists that have grown over time. Consider whether they can be split into more focused lists.
- **Last Updated By:** If the operator is not a known security administrator, investigate whether the change was authorized.
## Recommendations
1. Review flagged permission lists for excessive access
2. Consider splitting broad permission lists into more focused, role-specific lists
3. Verify that the "Last Updated By" operator is authorized to make security changes