Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***
I'm using gssproxy at my client for automatically getting a kerberos ticket for
a service, without user intervention. I installed and startet the service but
it  was not working until i figured, that I need to create this directory as it
is references in the default config file 99-nfs-client.config. And it has to be
recreated after each restart of my client as files in /tmp do not survive a
reboot.
So I have added an override to /etc/systemd/system/gssproxy.service.d:

[Service]
ExecStartPre=/bin/mkdir -p /tmp/gssproxy/clients
PrivateTmp=true

To actually be used by rpc-gssd.service a second overriide is neccessary for
this service:

[Service]
Environment=GSS_USE_PROXY=yes

Without these two additions gssproxy was not working on my client, so I think
they should be included in the package - or at least be mentioned in the docs
and may be as a comment in the configuration file.

Tobias Rupf <tobias.rupf@gmx.de> writes:

Hi and thanks for the report.  The /tmp/gssproxy/clients directory looks
weird, where is that path coming from?  I looked a bit in gssproxy
source code but didn't find what would create it.  Is this coming from
some kerberos configuration?  Could you give some step-by-step
instructions on how to reproduce this problem, from a freshly installed
debian system?

I believe the requirement to add GSS_USE_PROXY is fairly well
documented, see /usr/share/doc/gssproxy/docs/README.md.gz or URL below.
There is a systemd service file example that matches your setup.

https://github.com/gssapi/gssproxy/tree/main/docs#configuring-the-application

/Simon

Am Samstag, 26. Oktober 2024, 20:37:06 CET schrieb Simon Josefsson:
Of course this directory does not exist as systemd uses and creates
private tmp directories. You should instead find a directory like
/tmp/systemd-private-<some-id-string>-gssproxy.service-<some string>
on your system which is created by systemd at startup of gssproxy-
service. Gssproxy needs it to place krb5cc credentials there.
The override creates the neccessary sub folders inside this directory.
Without the override the subfolders are missing and gssproxy can not find
a location to place the credential-files for the users (hence gssproxy does
not create subfolders in /tmp resp. its private /tmp itself)
Yes it is well documented, nevertheless the override is required and I think it
should be included in the Debian gssproxy package. With override a mean a file
should be installed in /etc/systemd/system/rpc-gssd.service.d containing the
2 lines:
[Service]
Environment=GSS_USE_PROXY=yes
as described in my original report. A common user would expect gssproxy to work
and to be used right after installation of the package. That's why the report is
targeted to Debian project and not the gssproxy creator...

Tobias

Tobias Rupf <tobias.rupf@gmx.de> writes:

What is creating the files in that directory?  What software and
configuration is responsible for using /tmp/gssproxy/clients as the
intended path?  I can't find anything in the gssproxy package that
refers to that path, but I may be missing it.  What I suspect is that
something else is configured to use that path, and that is the component
that is responsible for also creating the directory.

We have a good regression testing of a Apache2+gssproxy setup that is
tested in debci/autopkgtest of the gssproxy package, and no extra
directory is necessary there.  See output:

https://salsa.debian.org/debian/gssproxy/-/jobs/6490012
https://salsa.debian.org/debian/gssproxy/-/blob/master/debian/tests/gssproxy-apache

Having a similar script for your use-case would be nice, to make sure it
keeps working.  I think your use-case is different from the apache2
use-case since you want the service to acquire user tickets?  I'm not
sure if getting tickets as the apache2 server on behalf of the user is
possible to do, and if so maybe doing so in this script will trigger
your use-case.

How should the gssproxy package know that you want to use gssproxy with
rpc-gssd?  Gssproxy can be used with a lot of applications and
GSS_USE_PROXY has to be enabled for each application the user wants to
use it for.  Having gssproxy add overrides unconditionally and by
default for rpc-gssd, apache2, dovecot, etc seems odd to me.  Some users
may want to use it with apache2 and NOT rpc-gssd, and some may want to
use it with rpc-gssd and NOT apache2.  That's why this is configurable,
I suppose.  Indeed this is a bad limitation of the current gssproxy
design, since it makes it harder to use, but I think it is intentional.

/Simon

Am Sonntag, 27. Oktober 2024, 10:35:30 CET schrieben Sie:
I'm using it gssproxy for kerberos with nfsv4 and the config file
/etc/gssproxy/99-nfs-client.conf is telling to use this directory
in it's cred_store line:
cred_store = ccache:FILE:/tmp/gssproxy/clients/krb5cc_%U
A similiar file is included in the doc as example:
/usr/share/doc/gssproxy/examples/99-network-fs-clients.conf
Of course you could modify the line to use the /tmp directory without
sub directories, or add a comment to the file to make the user aware,
that he must make sure himself to create the subdirectories...
OK, I see, one can see it that way. In my opinion I would think to use it for all
those as I don't see any reason why to enable it for one service but not for the
other. You can still leave a service out by just not configuring a client keytab for
it. It just took me some days to figure all that out and I'd like to make live easier
for others.

-------------------------------------------------------------