Jeff Bailey <[EMAIL PROTECTED]> writes:
> > Assuming the public key to be authorized is already readable by the
> > user in question, it occurs to me that
> >
> > lsh-authorize -u user key
> >
> > would be more or less equivalent to
> >
> > su user lsh-authorize key
>
> Hmm.. A little less equiv, I think: When you su to the user, you no
> longer have access to the files that root does.
I know, that why I wrote "assuming that ..." above.
> Every program I've seen defines 'HOME' for current user. In your script
> you refer to ~ for the users home directory, so I was just going to
> append the option username to that - ~$username or something. I'll have
> to try it, but I think it will be that easy for most Bourne shells.
*bonk* I had forgotten about ~user expansion.
Hmm, looking at the lsh-authorize another way to make it do the right
thing is to to su the sexp-conv command. I.e. replacing
$SEXP_CONV < $1 -f canonical --once > ~/.lsh/authorized_keys_sha1/$hash
with
cat $1 | su "$USER" /bin/sh -c \
"$SEXP_CONV -f canonical --once > "'~/.lsh/authorized_keys_sha1/'"$hash"
It's a little tricky, cat and expansion of $SEXP_CONv and $hash must
be done by the parent shell, while ~ is expanded by the subshell
running as a different user. And $SEXP_CONV must not expand to a
relative path.
(cat key | su lsh-authorize - won't work, as lsh-authorize reads the
keyfile twice).
Happy hacking,
/Niels
