Hi,
Le 30/04/2020 à 20:23, Robbie Harwood a écrit :
> Hi Vincent,
>
> I disagree about "usually", but I have a larger question, which is: why are
> you using gssproxy if you want the credentials in an easily accessible
> location? The entire point of the daemon is privilege separation.
I'm using gssproxy because I've some (cron jobs) system users
that must access to the NFS. For them, I add a keytab using
client_keytab:/var/lib/gssproxy/clients/%U.keytab
If I understand correctly, classical (normal, loggued) users
already have their credential and, in this case, gssproxy
should not be used?
In fact, this is linked to my other bug report
(#959190 that I put in CC) where you just point me to the
fact that I can totally disable the logs.
My use case is a machine with a kerberized NFS.
Logged users (with kerberos credentials) generates lots of
logs (as told in #959190) unless gssproxy is pointed to
their file credential.
When gssproxy is complaining, these users still can access
to the NFS (so I suspect that after gssproxy failure, classical
credential retrieval is used).
With your explanation, I understand now that gssproxy
config should not be changed and was correct (so #959186
can be closed). But it means that, under normal and default
config, gssproxy can generate lots of logs.
The admin can totally disable the logs as you told me,
but it means that he will not have any information in case
of problems. I will do this for now as I cannot handle
several GB of logs per days when some application are
running, but I would suggest that a way for gssproxy to
limits its logs (rate limit and/or log only the first messages
of similar messages or ...) would be way better.
Many thanks for your information
Regards
Vincent
> Thanks,
> --Robbie
>
> On April 30, 2020 10:48:29 AM EDT, Vincent Danjean <[email protected]>
> wrote:
>> Package: gssproxy
>> Version: 0.8.0-1.1
>> Severity: normal
>>
>> Hi,
>>
>> The default configuration file looks for kerberos credentials
>> in ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U but they usually
>> are in ccache:FILE:/tmp/krb5cc_%U
>> Is this configuration intended? Why? I had to change it, I found
>> the solution on several internet forum where it said that this is
>> an error in the default configuration. I'm not sure if this is the
>> case (an error) or if the default configuration file targets another
>> usage.
>>
>> Regards
>> Vincent
>>
>> -- System Information:
>> Debian Release: 10.3
>> APT prefers stable
>> APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
>> 'oldstable-updates'), (500, 'testing'), (500, 'oldstable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/30 CPU cores)
>> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
>> TAINT_UNSIGNED_MODULE
>> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8),
>> LANGUAGE=C.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages gssproxy depends on:
>> ii libc6 2.28-10
>> ii libgssapi-krb5-2 1.17-3
>> ii libgssrpc4 1.17-3
>> ii libini-config5 0.6.1-2
>> ii libk5crypto3 1.17-3
>> ii libkrb5-3 1.17-3
>> ii libpopt0 1.16-12
>> ii libref-array1 0.6.1-2
>> ii libselinux1 2.8-1+b1
>> ii libverto1 0.3.0-2
>>
>> gssproxy recommends no packages.
>>
>> gssproxy suggests no packages.
>>
>> -- Configuration Files:
>> /etc/gssproxy/99-nfs-client.conf changed:
>> [service/nfs-client]
>> mechs = krb5
>> cred_store = keytab:/etc/krb5.keytab
>> cred_store = ccache:FILE:/tmp/krb5cc_%U
>> cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
>> cred_usage = initiate
>> allow_any_uid = yes
>> trusted = yes
>> euid = 0
>>
>>
>> -- no debconf information
--
Vincent Danjean GPG key ID 0xD17897FA [email protected]
GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
