Discussion:
[systemd-devel] systemd/automount for multiple users using Kerberos
Sebastian Treiber
2017-04-05 14:28:50 UTC
Permalink
Dear members of the Systemd mailing list,

for a long time I have been struggling with a problem which sounds
relatively easy:
I have a cifs file server and a Linux (CentOS 7) client. On the client I
want to mount a share from the file server using Kerberos.
Only the root user can perform the mount but typically it has no
Kerberos ticket. A user, on the other hand, has a Kerberos ticket but
must not mount anything.
That means the mount has to be done by the root user and the uid of a
user who has a valid Kerberos ticket has to be used as an option. For
example:
mount.cifs //path_to_file_server/share /mount_point -o sec=krb5,cruid=123456
So far so good. However, on the client there are multiple users and each
one wants to be able to mount the share to the same directory.
As to my knowledge, autofs is the only tool which provides a solution
for that (you can use something like "$USER" in the autofs configuration
file).

Systemd has a automount functionality as well and I was hoping to
replace autofs by systemd/automount since autofs is very unstable (as to
my experience).
Despite heavy googling I could not find a solution using
systemd/automount (or any other than autofs). My problem is that I
cannot specify the user-ID dynamically but only as a static string in
the ".mount" unit file (or fstab).
Does anyone of you know if this is possible with systemd?

Kind regard,

Sebastian
--
Mit freundlichen GrÌßen
*Dr. Sebastian Treiber* | Systemanalytiker


GNS Systems - IT Dienstleistungen fÃŒr Engineering
<http://www.gns-systems.de>

GNS Systems GmbH
FronÀckerstraße 36/1
71063 Sindelfingen
Tel.: +49 (0)7031/68838-66
Fax: +49 (0)7031/68838-11


GeschÀftsfÌhrer: Christopher Woll
Sitz des Unternehmens: Braunschweig
Registergericht: Amtsgericht Braunschweig
Registernummer: HRB 4890
gns-systems.de <http://www.gns-systems.de>
Mantas Mikulėnas
2017-04-06 17:58:51 UTC
Permalink
On Wed, Apr 5, 2017 at 5:28 PM, Sebastian Treiber <
Post by Sebastian Treiber
Dear members of the Systemd mailing list,
for a long time I have been struggling with a problem which sounds
I have a cifs file server and a Linux (CentOS 7) client. On the client I
want to mount a share from the file server using Kerberos.
Only the root user can perform the mount but typically it has no Kerberos
ticket. A user, on the other hand, has a Kerberos ticket but must not mount
anything.
That means the mount has to be done by the root user and the uid of a user
cifs supports `-o multiuser`, which allows each UID to use a separate
session. So you can perform the mount as root using the machine credentials
(keytab) or another dedicated account, and each user will automatically use
their own credentials when accessing the share.
--
Mantas Mikulėnas <***@gmail.com>
Sebastian Treiber
2017-04-07 08:37:06 UTC
Permalink
Dear Mantas,

thank you very much for your reply.
At least on my system (CentOS7) this does not work. The mount process
tries to mount the share as root even when specifying "multiuser":
From /etc/fstab:
//cifs_filer/share /mount_point cifs
sec=krb5,multiuser,x-systemd.automount 0 0

From "journalctl -xf":
Apr 07 10:31:03 <hostname> cifs.upcall[78691]: sec=1
Apr 07 10:31:03 <hostname> cifs.upcall[78691]: uid=0
Apr 07 10:31:03 <hostname> cifs.upcall[78691]: creduid=0
Apr 07 10:31:03 <hostname> cifs.upcall[78691]: user=root
Apr 07 10:31:03 <hostname> cifs.upcall[78691]: pid=78686
Apr 07 10:31:03 <hostname> cifs.upcall[78691]: find_krb5_cc: considering
/tmp/krb5cc_1861017645
Apr 07 10:31:03 <hostname> cifs.upcall[78691]: find_krb5_cc:
/tmp/krb5cc_1861017645 is owned by 1861017645, not 0
Apr 07 10:31:03 <hostname> cifs.upcall[78691]: find_krb5_cc: considering
/tmp/krb5cc_1860718904_nEIDDll408
Apr 07 10:31:03 <hostname> cifs.upcall[78691]: find_krb5_cc:
/tmp/krb5cc_1860718904_nEIDDll408 is owned by 1860718904, not 0
Apr 07 10:31:03 <hostname> cifs.upcall[78691]: find_krb5_cc: considering
/tmp/krb5cc_1860718904
Apr 07 10:31:03 <hostname> cifs.upcall[78691]: find_krb5_cc:
/tmp/krb5cc_1860718904 is owned by 1860718904, not 0
Apr 07 10:31:03 <hostname> cifs.upcall[78691]:
krb5_get_init_creds_keytab: -1765328203

Is that intended behavior or not?

Best regards,

Sebastian
Post by Mantas Mikulėnas
On Wed, Apr 5, 2017 at 5:28 PM, Sebastian Treiber
Dear members of the Systemd mailing list,
for a long time I have been struggling with a problem which sounds
I have a cifs file server and a Linux (CentOS 7) client. On the
client I want to mount a share from the file server using Kerberos.
Only the root user can perform the mount but typically it has no
Kerberos ticket. A user, on the other hand, has a Kerberos ticket
but must not mount anything.
That means the mount has to be done by the root user and the uid
of a user who has a valid Kerberos ticket has to be used as an
cifs supports `-o multiuser`, which allows each UID to use a separate
session. So you can perform the mount as root using the machine
credentials (keytab) or another dedicated account, and each user will
automatically use their own credentials when accessing the share.
--
--
Mit freundlichen GrÌßen
*Dr. Sebastian Treiber* | Systemanalytiker


GNS Systems - IT Dienstleistungen fÃŒr Engineering
<http://www.gns-systems.de>

GNS Systems GmbH
FronÀckerstraße 36/1
71063 Sindelfingen
Tel.: +49 (0)7031/68838-66
Fax: +49 (0)7031/68838-11


GeschÀftsfÌhrer: Christopher Woll
Sitz des Unternehmens: Braunschweig
Registergericht: Amtsgericht Braunschweig
Registernummer: HRB 4890
gns-systems.de <http://www.gns-systems.de>
Mantas Mikulėnas
2017-04-07 08:57:35 UTC
Permalink
On Fri, Apr 7, 2017 at 11:37 AM, Sebastian Treiber <
Post by Sebastian Treiber
Dear Mantas,
thank you very much for your reply.
At least on my system (CentOS7) this does not work. The mount process
It's intended – the initial mount still happens the same way (using root or
machine credentials). The difference is that it doesn't need to match the
regular user anymore – *after* the share is mounted, if user 1000 tries to
access it, the system will automatically use that user's ticket.

To avoid needing to kinit as root, I would probably run k5start [1] as a
service.

[1]: https://www.eyrie.org/~eagle/software/kstart/
--
Mantas Mikulėnas <***@gmail.com>
Loading...