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?
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.
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.
Best,
Francis
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland