[OpenAFS] k5start and AFS tokens

[Jaap Winius]

Hi folks,

How should k5start (kstart 4.1-2 on Debian wheezy) be configured for
/etc/inittab to maintain a Kerberos ticket *and* an AFS token for an
arbitrary server process not running as root?

The -t option seems to do nothing for me, while any command option
placed at the end of the statement only causes another problem that
makes init disable the process after respawning too quickly.

For example:

KQ:2345:respawn:/usr/bin/k5start -U -f /etc/zz.keytab -K 10 -l 24h \
-k /tmp/krb5cc_99 -o zz -t

A Kerberos TGT is created for the zz user (ID 99) along with an AFS
service ticket, but no AFS token appears. However, if I run 'sudo -u
zz aklog' afterwards, the AFS token is created without any problem.

~# k5start -U -f /etc/zz.keytab -k /tmp/krb5cc_99 -o zz -t

A manual test that yields the same result.

~# KINIT_PROG=/usr/bin/aklog ; k5start -U -f /etc/krb5-minidlna.keytab \
-k /tmp/krb5cc_107 -o minidlna -t

Again, same result (just in case k5start was attempting to start aklog
from the wrong location).

~# k5start -U -f /etc/zz.keytab -k /tmp/krb5cc_107 \
-o minidlna /root/ma

Here, -t is replaced by a command, /root/ma, a shell script with a
single line: '/usr/bin/sudo -u zz /usr/bin/aklog'. This actually
works, producing a Kerberos TGT, an AFS service ticket and an AFS
token. But, all attempts to use this use in /etc/inittab have resulted
in fast respawns followed by init disabling it.

Any idea what I'm doing wrong?

Thanks,

Jaap

[Brandon Allbery]

Post by Jaap Winius
The -t option seems to do nothing for me, while any command option
placed at the end of the statement only causes another problem that
makes init disable the process after respawning too quickly.

This is because, if you specify a command, it runs that command and then
cleans up and exits. It's specifically intended to run a long-running
command or daemon while maintaining Kerberos tickets and optionally AFS
tokens for that command.

Which leads to the correct solution: instead of running your long
running daemon and having a separate k5start to maintain tickets/tokens
for it, use k5start to run the daemon so it can manage the
tickets/tokens for it directly.

--
brandon s allbery kf8nh sine nomine associates
***@gmail.com ***@sinenomine.net
unix openafs kerberos infrastructure xmonad http://sinenomine.

[Jaap Winius]

Post by Brandon Allbery
This is because, if you specify a command, it runs that command and
then cleans up and exits. It's specifically intended to run a
long-running command or daemon while maintaining Kerberos tickets
and optionally AFS tokens for that command. Which leads to the
correct solution: instead of running your long running daemon and
having a separate k5start to maintain tickets/tokens for it, use
k5start to run the daemon so it can manage the tickets/tokens for it
directly.

So, I was getting into trouble because aklog is not a long-running
command? Anyway, the daemon in question doesn't understand Kerberos or
AFS; I'm just trying to give an average daemon access to some files in
AFS. I thought k5start and its -t option would suffice, but perhaps I
wasn't using it properly. Any advice on that? If not, I suppose I can
always just make a cron job to run aklog every once in a while, but I
was hoping for a more elegant solution.

Thanks,

Jaap

[Benjamin Kaduk]

Post by Brandon Allbery
This is because, if you specify a command, it runs that command and
then cleans up and exits. It's specifically intended to run a
long-running command or daemon while maintaining Kerberos tickets
and optionally AFS tokens for that command. Which leads to the
correct solution: instead of running your long running daemon and
having a separate k5start to maintain tickets/tokens for it, use
k5start to run the daemon so it can manage the tickets/tokens for it
directly.

So, I was getting into trouble because aklog is not a long-running command?
Anyway, the daemon in question doesn't understand Kerberos or AFS; I'm just
trying to give an average daemon access to some files in AFS. I thought
k5start and its -t option would suffice, but perhaps I wasn't using it
properly.

It sounds like that's the case.

You want something like "k5start -t /path/to/long-running-command"
(include the other relevant arguments, of course).

Passing -t tells k5start to literally run 'aklog' (unless AKLOG is set in
the environment), not /path/to/long-running-command, when it gets tickets.

-Ben

[Jaap Winius]

Post by Benjamin Kaduk
Passing -t tells k5start to literally run 'aklog' (unless AKLOG is set in
the environment), not /path/to/long-running-command, when it gets tickets.

Well, that's all I want it to do, in addition to keeping a Kerberos
ticket alive.

In the mean time, I've actually succeeded in doing what I want, but
only for root:

KT:2345:respawn:/usr/bin/k5start -U -f /etc/krb5.keytab -K 10 -l 24h -t

This creates Kerberos TGT, an AFS service ticket and -- thanks to the
-t option -- an AFS token. Now, how can I do this for a user other
than root?

Cheers,

Jaap

[Dirk Heinrichs]

Post by Jaap Winius
This creates Kerberos TGT, an AFS service ticket and -- thanks to the
-t option -- an AFS token. Now, how can I do this for a user other
than root?

Use su in front of k5start and make sure the user has read access to the
keytab.

HTH...

Dirk

[Benjamin Kaduk]

Post by Benjamin Kaduk
Passing -t tells k5start to literally run 'aklog' (unless AKLOG is set in
the environment), not /path/to/long-running-command, when it gets tickets.

Well, that's all I want it to do, in addition to keeping a Kerberos ticket
alive.
In the mean time, I've actually succeeded in doing what I want, but only for
KT:2345:respawn:/usr/bin/k5start -U -f /etc/krb5.keytab -K 10 -l 24h -t
This creates Kerberos TGT, an AFS service ticket and -- thanks to the -t
option -- an AFS token. Now, how can I do this for a user other than root?

I think this is still in the "wrong" paradigm. (I mean, if it works for
you, don't go changing it just because I said so.)

The k5start mindset is to avoid having to have a separate periodic process
that prepares tickets/tokens for some independent process to consume --
instead, the process consuming the tickets/tokens is a child process,
wrapped by k5start. Thus, the k5start invocation should be placed at the
same location as the invocation of the consumer of the tickets/tokens, and
k5start will fork/exec the consumer process. That way the two processes
are related to each other and it's much easier to get them in the same
PAG/session keyring/etc.


-Ben

[Jaap Winius]

Post by Benjamin Kaduk
The k5start mindset is to avoid having to have a separate periodic process
that prepares tickets/tokens for some independent process to consume --
instead, the process consuming the tickets/tokens is a child process,
wrapped by k5start. ...

Are you suggesting that I not start k5start from /etc/inittab, but
instead alter the /etc/init.d/ script that starts up the daemon in
question, for instance so that the start-stop-daemon invocation starts
k5start that in turn starts up the daemon? And maybe then the -t
option will work?

Cheers,

Jaap

[Benjamin Kaduk]

Post by Benjamin Kaduk
The k5start mindset is to avoid having to have a separate periodic process
that prepares tickets/tokens for some independent process to consume --
instead, the process consuming the tickets/tokens is a child process,
wrapped by k5start. ...

Are you suggesting that I not start k5start from /etc/inittab, but instead
alter the /etc/init.d/ script that starts up the daemon in question, for
instance so that the start-stop-daemon invocation starts k5start that in turn
starts up the daemon? And maybe then the -t option will work?

That's the general idea, yes. I suppose it can get messy if there are
pidfiles involved, and I haven't read the details of the manpage to see
how that works, but that's what I imagine the "typical deployment" being.

-Ben

[Jaap Winius]

Are you suggesting that I alter the /etc/init.d/ script that starts
up the daemon in question, ...

That's the general idea, yes. ...

Okay, I figured it out. I altered /etc/init.d/zz by adding the
following line to the do_start function just before the zz daemon is
started up:

start-stop-daemon --start --pidfile /run/zz/k5start-zz.pid \
--chuid $USER:$GROUP --exec /usr/bin/k5start -- \
-b -p /run/zz/k5start-zz.pid \
-K 10 -l 24h -k /tmp/krb5cc_107 -o zz \
-L -t -U -f /etc/krb5-zz.keytab

The trick was to add the --chuid option so that k5start is run with
the UID/GID of the zz daemon; otherwise k5start will run aklog as root
and the desired AFS token will not be created (Dirk was correct). In
addition, I created the /run/zz/ directory, owned by the zz user, so
that k5start would be allowed to save the PID file there.

And in case anyone might be wondering, this is what I added to the
do_stop function in /etc/init.d/zz after the zz daemon is stopped:

/usr/bin/sudo -u zz /usr/bin/unlog
/usr/bin/sudo -u zz /usr/bin/kdestroy
start-stop-daemon --stop --pidfile /run/zz/k5start-zz.pid

Thanks!

Jaap

[Dirk Heinrichs]

Post by Jaap Winius
Okay, I figured it out.

No, not quite yet, I'm afraid.

Post by Jaap Winius
I altered /etc/init.d/zz by adding the
following line to the do_start function just before the zz daemon is
start-stop-daemon --start --pidfile /run/zz/k5start-zz.pid \
--chuid $USER:$GROUP --exec /usr/bin/k5start -- \
-b -p /run/zz/k5start-zz.pid \
-K 10 -l 24h -k /tmp/krb5cc_107 -o zz \
-L -t -U -f /etc/krb5-zz.keytab

You don't let k5start start your zz daemon. IOW: You don't do the "start" part
of k5start, only the "k5" part.

Bye...

Dirk

[Jaap Winius]

Post by Dirk Heinrichs
You don't let k5start start your zz daemon. IOW: You don't do the
"start" part of k5start, only the "k5" part.

Okay, how about this?

start-stop-daemon --start --pidfile /run/zz/k5start-zz.pid \
--chuid $USER:$GROUP --exec /usr/bin/k5start -- -b \
-p /run/zz/k5start-zz.pid \
-K 10 -l 24h -k /tmp/krb5cc_107 -o zz \
-L -t -U -f /etc/krb5-zz.keytab \
$($DAEMON $DAEMON_ARGS) || return 2

This still produces a second PID files, /run/zz/k5start-zz.pid, in
addition the one specified for the zz daemon in $DAEMON_ARGS, so one
start-stop-daemon invocation is used to shut the zz process and the
other k5start.

Cheers,

Jaap

[Jaap Winius]

Post by Jaap Winius
start-stop-daemon --start --pidfile /run/zz/k5start-zz.pid \
--chuid $USER:$GROUP --exec /usr/bin/k5start -- -b \
-p /run/zz/k5start-zz.pid \
-K 10 -l 24h -k /tmp/krb5cc_107 -o zz \
-L -t -U -f /etc/krb5-zz.keytab \
$($DAEMON $DAEMON_ARGS) || return 2

Actually, this doesn't work too well. I don't know why, but although
it really did work for me earlier, now it only causes the daemon to
start up without k5start, which seems a bit odd. I tried replacing
"$($DAEMON $DAEMON_ARGS)" with "$DAEMON -- $DAEMON_ARGS" or "--
$DAEMON $DAEMON_ARGS", but both of those variations lead to the same
result. Can anyone explain why that is?

In the mean time, I still get the most consistent results by using two
separate start-stop-daemon invocations. I understand that this is not
ideal, since now the script will start the long-term daemon even if
k5start fails before it, but right now I don't have a better solution.

Cheers,

Jaap

[Andrew Deason]

On Tue, 30 Sep 2014 20:56:35 +0200

Post by Jaap Winius
In the mean time, I still get the most consistent results by using two
separate start-stop-daemon invocations. I understand that this is not
ideal, since now the script will start the long-term daemon even if
k5start fails before it, but right now I don't have a better solution.

I haven't read through this thread too closely, but it doesn't seem like
you've been given much of a concrete explanation of how you're supposed
to change a daemon startup invocation to a k5start-ified one. (But there
has been a lot of attempted explanation of what's going on or why
something doesn't work.)

So I'm not going to answer your immediate question, but just to try to
maybe help illustrate:

If you have an init script that at some point runs some long-running
command in the foreground (after forking etc), like:

/usr/sbin/whateverd --foreground

You should replace that with:

k5start -f /whatever.keytab -U --other-options -- /usr/bin/whateverd --foreground

(or /usr/bin/k5start, or $K5START or something)

But if the init script runs some command that daemonizes itself (it
forks, detaches, etc), you need to replace this:

/usr/sbin/whateverd --daemonize

with something like:

k5start -b -f /whatever.keytab -U --other-options -- /usr/sbin/whateverd --foreground

Note the '-b' option for k5start, and changing the whateverd invocation
from '--daemonize' to '--foreground'. If the long-running process does
not have a way of running in the foreground, I don't think you can do
this the 'proper' way that people have been suggesting.

And of course, all of this is just the arguably 'proper' way to use
k5start; that is, to wrap another command. You can just run k5start
separately and be decoupled from the other process, as I think you are
doing, and other people do do that. It's just not the "best" way to do
it (at least, according to some/most).

Also, if you want more feedback or more eyes on this or anything, you
can try mailing the kerberos list, since this isn't really AFS-specific.
I don't mean to say that this thread is inappropriate for here, but
just that that's another place to try if you wanted. Others may be more
used to answering questions like this there, and Russ would see it
there (iirc he doesn't read this list, or will not be reading it for
long).

[Brandon Allbery]

Post by Jaap Winius
So, I was getting into trouble because aklog is not a long-running
command? Anyway, the daemon in question doesn't understand Kerberos or
AFS; I'm just trying to give an average daemon access to some files in
AFS.

That is *exactly* the use case for k5start; it adds the Kerberos/AFS
"awareness" to the program it runs, as it were. Use k5start to launch
the daemon, and k5start will maintain the tickets/tokens the daemon
doesn't know it needs and will do so as long as the daemon is running.

--
brandon s allbery kf8nh sine nomine associates
***@gmail.com ***@sinenomine.net
unix openafs kerberos infrastructure xmonad http://sinenomi