[Samba] cifsacl not working - RESOLVED

Aurélien Aptel aaptel at suse.com
Mon Sep 28 10:30:08 UTC 2020

Ken Bass <kbass at kenbass.com> writes:
> However the package only has a 'suggestion' of the keyutils package. 
> Without installing keyutils which creates the
> /etc/request-key.conf file AND installed the /sbin/request-key binary,

What is really needed is the request-key binary. I suspect the
request-keys.d dir and its content was enough.

keyutils is definitely a requirement for any of the advanced feature of
cifs.ko to work.

> the 'cifsacl' option doesn't work / perform the winbind mapping as it 
> should.

That's correct. cifsacl requires cifs.idmap and keyutils.

cifs.ko delegates some of the complex work to userspace, specifically:
* kerberos auth (the security binary blob sent in Session Setup)
* dns resolving (when it happens in kernel space: DFS, failover, reconnection)
* id mapping (with cifsacl, which uid/gid to return given a SID)

System calls are initiated by userspace and call into kernel space. They
cannot be used the other way around, when kernel space wants to call
userspace ("upcall"). For this the kernel uses the keyring system.

This keyring system is not limited to crypto keys as its name might
suggest. It is used as a generic key-value store. There are user space
and kernel space API to access it. Entries have a key, key type,
description, value, access permissions, and optionnal expiracy time
(with which entries can basically become a cache).

When a caller of the keyring API looks for a key that doesn't exist or
exists but is expired, the request-key program is called. That program
reads the request-key.conf file (or request-key.d dir) which specifies
which program should be called for which key types. For example:

    create  cifs.idmap    * * /usr/sbin/cifs.idmap %k

The /usr/sbin/cifs.idmap program will be called by the kernel for any
non-existing or expired mapping of type "cifs.idmap". That program is
expected to set the missing entry by using the userspace keyring API.

Some commands to explore your system keys:

# cat /proc/keys
# keyctl show

Note that keyring can be global, persession, per process, per thread,
per uid, .... and can be nested in hierarchies. Also some entries might
be set to not be readable from userspace (even by root).


Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)

More information about the samba mailing list