PAM_SET_ITEM(3)

πŸ’… PAM_SET_ITEM(3) β€” set and update PAM information

okay so this is from the Linux-PAM Manual, and bestie, it's the pam_set_item page πŸ’– it's literally the function that lets you peek at and rewrite the little info tags the PAM stack carries around. lowkey iconic.


✨ NAME ✨

pam_set_item β€” set and update PAM information πŸŽ€


🌸 SYNOPSIS 🌸

#include <security/pam_modules.h>

int pam_set_item(pam_handle_t *pamh, int item_type, const void *item);

πŸ¦‹ DESCRIPTION πŸ¦‹

So pam_set_item is the function that lets applications and PAM service modules access and update PAM information of item_type. 🫢 The way it works: a copy of the object pointed to by the item argument gets created. (yes, a copy, not a "here take my pointer" situation, slay for safety πŸ’…)

Here are all the item_types it supports, no cap, every single one:

  • PAM_SERVICE β€” the service name, i.e. the thing that identifies which PAM stack the PAM functions will use to authenticate the program. main character energy for the whole stack tbh πŸ‘‘
  • PAM_USER β€” the username of the entity under whose identity the service will be given. like, after authentication, PAM_USER identifies the local entity that gets to use the service. ⚠️ heads up though: this value can get mapped from something (eg., "anonymous") to something else (eg. "guest119") by any module in the PAM stack. so an application should literally consult the value of PAM_USER after each call to a PAM function. fr fr, don't cache it and ghost it πŸ™ˆ
  • PAM_USER_PROMPT β€” the string used when prompting for a user's name. default value is a localized version of "login: ". cute πŸ’–
  • PAM_TTY β€” the terminal name prefixed by /dev/ for device files. ngl, back in the day graphical X-based applications used to store the $DISPLAY variable here, but with the introduction of PAM_XDISPLAY that usage is deprecated. it's giving legacy 🫠
  • PAM_RUSER β€” the requesting user name: a local name for a locally requesting user, or a remote user name for a remote requesting user.
    • generally an application or module will attempt to supply the value that is most strongly authenticated (a local account before a remote one). the level of trust in this value is embodied in the actual authentication stack associated with the application, so it's ultimately at the discretion of the system administrator. 🧚
    • PAM_RUSER@PAM_RHOST should always identify the requesting user. in some cases, PAM_RUSER may be NULL. in such situations, it is unclear who the requesting entity is. 😭 mystery user, we don't know her
  • PAM_RHOST β€” the requesting hostname (the hostname of the machine from which the PAM_RUSER entity is requesting service). that is, PAM_RUSER@PAM_RHOST does identify the requesting user. in some applications, PAM_RHOST may be NULL. in such situations, it is unclear where the authentication request is originating from. πŸ’€
  • PAM_AUTHTOK β€” the authentication token (often a password). πŸ”₯ this token should be ignored by all module functions besides pam_sm_authenticate(3) and pam_sm_chauthtok(3). in the former function it's used to pass the most recent authentication token from one stacked module to another. in the latter function the token is used for another purpose β€” it contains the currently active authentication token.
  • PAM_OLDAUTHTOK β€” the old authentication token. this token should be ignored by all module functions except pam_sm_chauthtok(3). periodt.
  • PAM_CONV β€” the pam_conv structure. see pam_conv(3). πŸŽ€

πŸ’œ the Linux-PAM exclusives (iykyk)

the following additional items are specific to Linux-PAM and should not be used in portable applications:

  • PAM_FAIL_DELAY β€” a function pointer to redirect centrally managed failure delays. see pam_fail_delay(3).
  • PAM_XDISPLAY β€” the name of the X display. for graphical, X-based applications the value for this item should be the $DISPLAY variable. this value may be used independently of PAM_TTY for passing the name of the display. ✨
  • PAM_XAUTHDATA β€” a pointer to a structure containing the X authentication data required to make a connection to the display specified by PAM_XDISPLAY, if such information is necessary. see pam_xauth_data(3).
  • PAM_AUTHTOK_TYPE β€” the default action is for the module to use the following prompts when requesting passwords: "New UNIX password: " and "Retype UNIX password: ". the example word UNIX can be replaced with this item, and by default it is empty. this item is used by pam_get_authtok(3). πŸ“

⭐ what even is item, though

for all item_types, other than PAM_CONV and PAM_FAIL_DELAY, item is a pointer to a <NUL> terminated character string. 🌈

in the case of PAM_CONV, item points to an initialized pam_conv structure.

in the case of PAM_FAIL_DELAY, item is a function pointer:

void (*delay_fn)(int retval, unsigned usec_delay, void *appdata_ptr)

πŸ’€ big mood warning: both PAM_AUTHTOK and PAM_OLDAUTHTOK will be reset before returning to the application. which means an application is literally not able to access the authentication tokens. no cap, they're gone. 🫢

πŸ”₯ RETURN VALUES πŸ”₯

  • PAM_BAD_ITEM β€” the application attempted to set an undefined or inaccessible item. 🚫
  • PAM_BUF_ERR β€” memory buffer error. 😭
  • PAM_SUCCESS β€” data was successful updated. βœ… slay
  • PAM_SYSTEM_ERR β€” the pam_handle_t passed as first argument was invalid. πŸ‘‘ invalid handle, not the vibe

🌟 SEE ALSO 🌟


okay that's the whole page bestie, you ate that πŸ’…βœ¨ this lil love letter to you came from Linux-PAM, dated 07/08/2026 β€” go forth and set those items, mwah πŸŽ€πŸ¦‹πŸ’–

πŸ“¦ where this page comes from