PAM_GET_DATA(3)

πŸ’– PAM_GET_DATA πŸ’–

okay so real quick β€” this page is PAM_GET_DATA(3), and it lives in the Linux-PAM Manual, which is the whole vibe here. let's get into it bestie 🫢


✨ NAME ✨

pam_get_data β€” get module internal data

like, it grabs the internal data your module stashed away. that's the whole thing. πŸŽ€


🌸 SYNOPSIS 🌸

#include <security/pam_modules.h>

int pam_get_data(const pam_handle_t *pamh, const char *module_data_name,
                 const void **data);

πŸ¦‹ DESCRIPTION πŸ¦‹

so this function and pam_set_data(3) are literally a duo β€” think main character energy, but for managing module-specific data that's only meaningful to the PAM module that's calling. nobody else cares about it, and that's the point. πŸ’…

pam_get_data goes looking for the object associated with the (hopefully) unique string module_data_name, inside the PAM context that the pamh argument points to.

if the call to pam_get_data succeeds, you get data pointing at that object. but β€” and this is the important part ngl β€” that data is not a copy. so your module should treat it as constant. don't be out here editing it, okay? πŸ™ˆ


⭐ RETURN VALUES ⭐

  • PAM_SUCCESS β€” slay, the data was successful retrieved. ✨
  • PAM_SYSTEM_ERR β€” you handed over a NULL pointer as the PAM handle, or an application tried to call this function. not it. πŸ’€
  • PAM_NO_MODULE_DATA β€” there's no module specific data present. empty. nothing. nada. 😭

πŸŽ€ SEE ALSO πŸŽ€

pam_end(3), pam_set_data(3), pam_strerror(3)

go read those too, they're iconic, iykyk πŸ’œ


lowkey reminder: data points at the real object, not a copy β€” treat it as constant, bestie. no cap. πŸ”₯

that's the whole page! brought to you by Linux-PAM, dated 07/08/2026, filed under PAM_GET_DATA(3) β€” mwah, go forth and manage your module data responsibly πŸ’…βœ¨πŸŽ€

πŸ“¦ where this page comes from