cifs.upcall(8)

okay so bestie, today we're doing cifs.upcall(8) β€” a page straight outta the System Manager's Manual, and it's giving "tiny helper program that the kernel literally cannot function without." no cap. let's get into it πŸ’…βœ¨

πŸŽ€ NAME πŸŽ€

cifs.upcall β€” userspace upcall helper for Common Internet File System (CIFS) πŸ¦‹


🌸 SYNOPSIS 🌸

cifs.upcall [--trust-dns|-t] [--version|-v] [--legacy-uid|-l]
[--debug|-d]
       [--krb5conf=/path/to/krb5.conf|-k /path/to/krb5.conf]
       [--keytab=/path/to/keytab|-K /path/to/keytab] [--expire|-e
       nsecs] {keyid}

like. look at her. flags everywhere. she's doing the most and honestly? she's serving πŸ’–


πŸ’œ DESCRIPTION πŸ’œ

This tool is part of the cifs-utils suite. iykyk.

cifs.upcall is a userspace helper program for the linux CIFS client filesystem. so here's the tea: there's a bunch of stuff the kernel genuinely cannot easily do by itself, and this program is the callout program that does those things for the kernel and then hands back the result. main character energy fr fr β€” kernel asks, cifs.upcall delivers, everyone moves on with their life 😭

cifs.upcall is generally intended to be run when the kernel calls request-key(8) for a particular key type. and yes, technically you can run it straight from the command-line, but bestie… it's not generally intended to be run that way. it's a behind-the-scenes girlie. let her cook πŸ“


✨ OPTIONS ✨

  • -c β€” 🚩 this option is deprecated and is currently ignored. that's it. that's the whole vibe. it does literally nothing.
  • --debug|-d β€” Enable debug logs. By default no debug messages are logged, only errors. so if you're like "why is nothing happening" β€” it's because she's silent by default, bestie πŸ™ˆ
  • --no-env-probe|-E β€” Normally, cifs.upcall will probe the environment variable space of the process that initiated the upcall in order to fetch the value of $KRB5CCNAME. this can assist the program with finding credential caches in non-default locations. If this option is set, then the program won't do this and will rely on finding credcaches in the default locations specified in krb5.conf. Note that this is never performed when the uid is 0. The default credcache location is always used when the uid is 0, regardless of the environment variable setting in the process. periodt. πŸ’…
  • --krb5conf|-k=/path/to/krb5.conf β€” This option allows administrators to set an alternate location for the krb5.conf file that cifs.upcall will use. admin girlies, this one's for you πŸ‘‘
  • --keytab=|-K=/path/to/keytab β€” This option allows administrators to specify a keytab file to be used. When a user has no credential cache already established, cifs.upcall will attempt to use this keytab to acquire them. The default is the system-wide keytab /etc/krb5.keytab. so like, if you got no creds, she'll go grab them from the keytab. resourceful queen 🌈
  • --trust-dns|-t β€” With krb5 upcalls, the name used as the host portion of the service principal defaults to the hostname portion of the UNC. This option allows the upcall program to reverse resolve the network address of the server in order to get the hostname.
⚠️ This is less secure than not trusting DNS. When using this option, it's possible that an attacker could get control of DNS and trick the client into mounting a different server altogether. 😭 bestie. that's a whole man-in-the-middle situation.

It's preferable to instead add server principals to the KDC for every possible hostname, but this option exists for cases where that isn't possible. The default is to not trust reverse hostname lookups in this fashion. so like, default is safe, this flag is the spicy one 🌢️

  • --legacy-uid|-l β€” Traditionally, the kernel has sent only a single uid= parameter to the upcall for the SPNEGO upcall that's used to determine what user's credential cache to use. This parameter is affected by the uid= mount option, which also governs the ownership of files on the mount.

Newer kernels send a creduid= option as well, which contains what uid it thinks actually owns the credentials that it's looking for. At mount time, this is generally set to the real uid of the user doing the mount. For multisession mounts, it's set to the fsuid of the mount user. Set this option if you want cifs.upcall to use the older uid= parameter instead of the creduid= parameter. lowkey a nostalgia flag 🫢

  • --expire|-e β€” Override default timeout value (600 seconds) for dns_resolver key. numbers don't lie πŸ’€
  • --version|-v β€” Print version number and exit. she said "i'm done here" ✨

🌈 ENVIRONMENT VARIABLES 🌈

  • GSS_USE_PROXY="yes" β€” Enable usage of gssproxy for credential retrieval. This includes keytab based client initiation as well as (Resource Based) Constrained Delegation. See gssproxy-mech(8). delegation? constrained?? resource based??? we love a multi-talented setup ✨

πŸ‘‘ CONFIGURATION FOR KEYCTL πŸ‘‘

cifs.upcall is designed to be called from the kernel via the request-key callout program. This requires that request-key be told where and how to call this program. The current cifs.upcall program handles two different key types:

cifs.spnego

This keytype is for retrieving kerberos session keys πŸ”‘

dns_resolver

This key type is for resolving hostnames into IP addresses. Support for this key type may eventually be deprecated (see below). πŸ‘€ foreshadowing


To make this program useful for CIFS, you'll need to set up entries for them in request-key.conf(5). Here's an example of an entry for each key type:

#OPERATION  TYPE           D C PROGRAM ARG1 ARG2...
#=========  =============  = = ================================
create      cifs.spnego    * * /usr/bin/cifs.upcall %k
create      dns_resolver   * * /usr/bin/cifs.upcall %k

See request-key.conf(5) for more info on each field. no skimming, bestie, read the fields πŸ“–


The keyutils package has also started including a dns_resolver handling program as well that is preferred over the one in cifs.upcall. If you are using a keyutils version equal to or greater than 1.5, you should use key.dns_resolver to handle the dns_resolver keytype instead of cifs.upcall. See key.dns_resolver(8) for more info.

πŸ’‘ so yeah β€” that "may eventually be deprecated" thing from earlier? this is the plot twist. if you're on keyutils >= 1.5, hand that keytype to key.dns_resolver. the girls that get it, get it 🧚

πŸ’– SEE ALSO πŸ’–

request-key.conf(5), mount.cifs(8), key.dns_resolver(8)

go read them. they're linked for a reason. it's giving "required reading" πŸŽ€


🌸 AUTHOR 🌸

Igor Mammedov wrote the cifs.upcall program.

Jeff Layton authored this manpage.

The maintainer of the Linux CIFS VFS is Paulo Alcantara.

The Linux CIFS Mailing list is the preferred place to ask questions regarding these programs. besties, ask there, not in my DMs 🫢


and that's the whole page, babes πŸ’… this one lives in the System Manager's Manual and its footer is just cifs.upcall(8) looking cute with no extra drama β€” so congrats, you now know the entire thing, top to bottom, every flag intact. slay, ate, no crumbs left. mwah πŸŽ€πŸ’–βœ¨

πŸ“¦ where this page comes from