google / libpam-policycache Goto Github PK

Modules like pam_unix.so have setuid-root helpers like unix_chkpwd so they work from applications like screensavers that run as the user.

The cache will need a similar helper, but it's not so straight-forward. The "check" action is safe to run in a helper, but the "update" action isn't. It's probably not wise to allow a user to set their own password arbitrarily using the helper without providing their old password.

The helper also can't accept arbitrary storage and policy paths, so only the defaults will be allowed for non-root users.

Until some clever solution is found for handling the update action, I'll just make "check" work when run as a normal user for that specific user only. That means the last_verified time and cached password will only be updated during login, sudo, etc. Users who have long-lived graphical sessions should only rely on policies that use a long "refresh" time.

It took me a little bit of time to find out one issue with this module is the ini-file style config - not renew: 1w but renew=1w. Could you please correct the Readme accordingly?

We rely on the cache storage directory's permissions to ensure that the cache entries are only readable by root. Instead, we should explicitly chmod the entry files to 0600 when they are written.

Dear Nikki VonHollen,

I'm currently using your pam module but I face the problem that pam_escalete doesn't seem to work (anymore), could you do a recompile in a Debian unstable environment and tell me if you can get any output from pam_escalete?

Kind regards
Harald Jenny

GTimeVal is deprecated in GLib 2.62, but this project currently uses this in util.c.

I have made some changes to the first 2 functions in util.c to make it work with newer versions of GLib, and thereby also make it compatible with Ubuntu 20.04, while maintaining backwards compatibility with macros:

/**
 * CacheUtilDatetimeToString:
 * @value: Date to create string from. Must be UTC.
 *
 * Returns: (allow-none): Date in "{yyyy}-{mm}-{dd}T{hh}:{mm}:{ss}Z" format
 * (ISO 8601) or #NULL if the date couldn't be serialized.
 */
gchar *CacheUtilDatetimeToString(GDateTime *value) {
  if (!value)
    return NULL;

#if GLIB_CHECK_VERSION(2, 62, 0)
  return g_date_time_format_iso8601(value);
#else
  GTimeVal tv = {0, 0};

  if (g_date_time_to_timeval(value, &tv)) {
    return g_time_val_to_iso8601(&tv);
  } else {
    return NULL;
  }
#endif
}


/**
 * CacheUtilDatetimeFromString:
 * @value: String containing the date, in the "{yyyy}-{mm}-{dd}T{hh}:{mm}:{ss}Z"
 * format (ISO 8601). Dates are always UTC.
 * @result: (out): GDateTime respresenting the given @value.
 *
 * Returns: #TRUE if @result was modified or #FALSE if the date couldn't be
 * parsed.
 */
gboolean CacheUtilDatetimeFromString(const gchar *value, GDateTime **result) {
  g_assert(result);

#if GLIB_CHECK_VERSION(2, 56, 0)
  GDateTime *dt = g_date_time_new_from_iso8601(value, g_time_zone_new_utc());

  if (dt) {
    *result = dt;
#else
  GTimeVal tv = {0, 0};

  if (g_time_val_from_iso8601(value, &tv)) {
    *result = g_date_time_new_from_timeval_utc(&tv);
#endif
    return TRUE;
  } else {
    return FALSE;
  }
}

I hope this can be of help to other users of libpam-policycache.

Kind regards,
Rune Lejbølle

feature request I guess

The current CachePolicyNewForUser in src/policy.c has to pick one section out of multiple possible matching sections. The current logic uses the first section it finds. Policy filenames are sorted before they are read.

@tokkee proposed an alternate way, picking the best match out of all possible matches. A section like [user:janedoe] would be picked before [group:allusers]. There's still the problem of ordering when multiple sections on the same level are chosen, but we can fallback to first-match between equal sections.

Why to choose first-match:

• Policy files can be more advanced.
• Figuring out what policy matches is more simple.
• The "disable=true" setting can blacklist certain users/groups before any other sections are tried.
• Netgroups can be preferred over groups.
• It's still required as a fallback in the best-match implementation.

Why to choose best-match:

• It's more intuitive. A [user:janedoe] section will always be picked for that user.
• It's more efficient. Querying large groups/netgroups can be very expensive, so it's nice to only do it when we know it's necessary.

What other pros/cons exist?

Dear Nikki VonHollen,

how do you think about adding yescrypt support as the default encryption method?

Kind regards
Harald Jenny

On Trusty and above we have libscrypt (https://github.com/technion/libscrypt) in the default repos.