---
Francis Augusto Medeiros-Logeay
Oslo, Norway
On 2023-03-23 16:06, Alexander Bokovoy via FreeIPA-users wrote:
On to, 23 maalis 2023, Francis Augusto Medeiros-Logeay wrote:
> Thanks a lot Alexander. I have some follow up questions,
>
>> On 23 Mar 2023, at 14:50, Alexander Bokovoy <abokovoy(a)redhat.com>
>> wrote:
>>
>> On to, 23 maalis 2023, Francis Augusto Medeiros-Logeay via
>> FreeIPA-users wrote:
>>> Hi,
>>>
>>> We use RHEL 8 with kerberos, and we are using NFSv4 for mounting
>>> home
>>> directories.
>>>
>>> We have experienced that some machines become unresponsive if a user
>>> has a job that writes to the home directory after his ticket has
>>> expired after the default lifetime (7 days in our case).
>>>
>>> While we are looking for ways to allow people to automatically get
>>> new
>>> tickets, we also want to have a mechanism to log users out if their
>>> tickets are too close expiration (as well as all their jobs and cron
>>> jobs).
>>>
>>> Is there a way to get the expiration date for user tickets for a
>>> given
>>> user with for example “klist", or only the user himself can get that
>>> info?
>>
>> klist already lists the expiration date and time. You need to parse
>> that
>> if you want to know it. As long as you have access to the ccache
>> (e.g.
>> klist runs within the user session scope or you can specify the
>> ccache
>> explicitly and have access to it), you have that information.
>
> We use KCM, and with a quick test I saw that, as root, I don’t get to
> read much, and I don’t get to know what’s the cache id.
>
> Any idea on how to circumvent that?
Well, 'su - user' might give you access to KCM's view of that user.
Other than that, it might not accessible.
>
>> systemd gives you a way to force out logout for a service:
>>
>> RuntimeMaxSec=
>> Configures a maximum time for the service to run. If this is
>> used and the service has been active for longer than the
>> specified time it is terminated and put into a failure state.
>> Note that this setting does not have any effect on
>> Type=oneshot services, as they terminate immediately after
>> activation completed. Pass "infinity" (the default) to
>> configure no runtime limit.
>>
>> If a service of Type=notify sends "EXTEND_TIMEOUT_USEC=...",
>> this may cause the runtime to be extended beyond
>> RuntimeMaxSec=. The first receipt of this message must occur
>> before RuntimeMaxSec= is exceeded, and once the runtime has
>> extended beyond RuntimeMaxSec=, the service manager will
>> allow the service to continue to run, provided the service
>> repeats "EXTEND_TIMEOUT_USEC=..." within the interval
>> specified until the service shutdown is achieved by
>> "STOPPING=1" (or termination). (see sd_notify(3)).
>
> The problem here - as I see it - is to start the count dynamically, in
> case the user, for example, renews his ticket by entering his password
> on another ssh session.
Yeah, this is not something to achieve this way.
>>
>> and logind gives a way to force killing processes on user's logout:
>>
>> KillUserProcesses=
>> Takes a boolean argument. Configures whether the processes of
>> a user should be killed when the user logs out. If true, the
>> scope unit corresponding to the session and all processes
>> inside that scope will be terminated. If false, the scope is
>> "abandoned", see systemd.scope(5), and processes are not
>> killed. Defaults to "no", but see the options KillOnlyUsers=
>> and KillExcludeUsers= below.
>>
>> In addition to session processes, user process may run under
>> the user manager unit user@.service. Depending on the linger
>> settings, this may allow users to run processes independent
>> of their login sessions. See the description of enable-linger
>> in loginctl(1).
>>
>> Note that setting KillUserProcesses=yes will break tools like
>> screen(1) and tmux(1), unless they are moved out of the
>> session scope. See example in systemd-run(1).
>
> Thanks. This is also a good tool. But I guess we need to find a way to
> scan possible cron jobs that starts exactly when the user isn’t logged
> in.
Indeed.
Thanks Alexander. So I guess that we do have to impersonate the user to
get this done, anyway. I wanted to avoid that route, but if that's what
it takes, so I guess that's what we'll have to do :)
Best,
Francis