Basically, I wanted to run NIS+ commands requiring authentication from
cron. The answer is: no clean way to do this. Lots of messy ways to do
it.
-As root. Because root can provide DES credentials to NIS+ anytime it
wants, by reading /etc/.rootkey. I don't like this solution because I
have yanked root's ability to modify NIS+ tables -- I want to delegate
that to other UIDs which have no authority over the file system but which
do have authority over given tables.
-By maintaining a live, logged in session for the relevant UID.
-Use expect ... disadvantage means maintaining a password in a text filei
-By giving "nobody" all permisssions to the relevant tables.
-By turning off DES authentication entirely.
Thanks to:
Stephen Harris <sweh@mpn.com>
john <john@usa.nai.net>
Francis Liu <fxl@pulse.itd.uts.edu.au>
Kevin Davidson <tkld@cogsci.ed.ac.uk>
SunSupport
Original query:
I would like to run a nisaddent operation as a job in a crontab. Works
fine when I run it manually, fails with "permission denied" when I run it
via cron.
I suspect that the problem is authentication. When I login, I acquire DES
keys and am authenticated to perform the relevant operation. When my
crontab runs ... there is no way for the job to acquire DES keys, since
I'm not around entering my password.
Does anyone know of a way around this?
Solaris 2.5.1
--sk
> Does anyone know of a way around this?
Horrible solution - turn off authentication - ie run rpc.nisd in a lower
security mode. By default it runs at level "2". Level "0" is no
security. man rpc.nisd for more details.
rgds
Stephen
> Does anyone know of a way around this?
Use expect. Not secure though since you have to put your key in
plaintext.
John
>
Why not stay logged in? Unless you explicitly do a keylogout your
credentials should stay valid.
Francis
sbk> Does anyone know of a way around this?
This sounds odd. If you were logged in on that machine and you did
not explicitly keylogout and the machine has not been rebooted, then
your secure RPC credentials should still be in tact - processes run
with your UID will have the secret key. You're sure this is not an
ordinary UNIX permissions problem ?
If your cron job must run after a reboot, then you'll need to do it
as root. Only root has the ability to automatically keylogin (via
/etc/.rootkey) when the machine is booted.
You could perhaps write a program to call getsecretkey() and
key_setsecret() before running your cron job, but you would need to
have your secure RPC password stored in plain text somewhere...
-- |Kevin.Davidson@edinburgh.ac.uk
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:14 CDT