User needs access to run certain commands

[lhiggie]

Good day all,

We are running TRU64 UNIX v 5.1 on an alpha box. I have a contractor who will be gathering trend information for a migration project and he has requested access to the following commands:

top, vmstat, iostat, ps, uerf, fstab, df, volprint, sysconfig, prsinfo -v, cat /proc/*, crontab -l and sizer -v

I have added him as a normal user. vmstat, iostat, ps, fstab, df, sysconfig, psrinfo -v and sizer -v all run beautifully, however, the remaining commands, won't run:

top yields /dev/kmem: Permission denied
uerf yields ERIT - Unable to open file /usr/adm/binary.errlog
volprint yields You are not privileged to run volprint
cat /proc/* yields cat: cannot open *
crontab -l root yields you are not authorized to use cront. Sorry.

1. With the top command it is attempting to access /dev/kmem which has perms of cr--r-----, so obviously anyone other than the owner and group root and mem can read it. What would be the consequences to make it cr--r--r--?
2. uerf usage appears to have a corrupt binary.errlog?
3. volprint has rwxr-xr-x permissions, so why wouldn't the user be able to run volprint?
4. Can you not cat /proc/00001 like you can in Linux?
5. Can you not list crontab for another user, most specifically root?

Thank you all in advance for your assistance!

Sincerely,
Lee

[Steven Schweda · Accepted solution]

> [...] TRU64 UNIX v 5.1 [...]

Actual "sizer -v" output would be better.

> [...] and sizer -v all run beautifully"
> [...]

Prove it.


> [...] so obviously anyone other than the
> owner and group root and mem can read it.

Not?

> What would be the consequences to make it cr--r--r--?

Bad, I'd assume. Around here, the SUID bit
is set on "top"

urtx> ls -l /usr/local/bin/top
-rwsr-xr-x 1 root mem 442144 Mar 12 2008 /usr/local/bin/top

The "top" documentation covers this.
(Including some cautions.) Seems (to me)
likely to be safer than giving away
"/dev/kmem".


> 2. uerf usage appears to have a corrupt
> binary.errlog?

It does? Evidence?

ls -lL /usr/adm/binary.errlog

I'd guess that its a permission problem.
Around here:

urtx> ls -lL /usr/adm/binary.errlog
-rw-r----- 1 root adm 840424 Aug 4 15:15 /usr/adm/binary.errlog

man acl


> 3. volprint has rwxr-xr-x permissions, so
> why wouldn't the user be able to run
> volprint?

I know nothing about volprint, but I could
write a program which looks at who's running
it, and exits with that message if it doesn't
like what it sees. If you like living
dangerously, you might be able to wrap a
volprint command in an SUID shell script.

Have you looked at the Tru64 docs regarding
volprint?


> 4. Can you not cat /proc/00001 like you can
> in Linux?

Did you try it? What happened? Tru64 is not
GNU/Linux.


> crontab -l root yields you are not
> authorized to use cront. Sorry.

man cron
or:
man crontab

Look for "/var/adm/cron/cron.allow" and
"/var/adm/cron/cron.deny".

[Steven Schweda]

> urtx> ls -l /usr/local/bin/top
> -rwsr-xr-x 1 root mem 442144 Mar 12 2008 /usr/local/bin/top
>
> The "top" documentation covers this.

Note that following the suggestion in the
"top" "FAQ" to add SGID (and change the group
to "mem", if it's different) will get you
past the "/dev/kmem: Permission denied"
complaint, but you still won't get any
process info. SUID seems to be needed for a
peon to get full functionality. At least
that's what I saw here with this one:

urtx> top -v
top: version 3.8beta1

For the record:

urtx> sizer -v
HP Tru64 UNIX V5.1B (Rev. 2650); Fri Mar 20 20:19:48 CDT 2009

[lhiggie]

Steven,

Thank you very much for your replies. I'm still piecing things together as these boxes were set up by different people at different times that had different ideas on setting up TRU64 servers.

I have assigned you points for your very quick and concise replies. Thank you again.

Sincerely,
Lee

[Pieter 't Hart]

have you looked at "dop"?

man dop :
dop - Allows a user to execute a privileged program without knowing the root password.

[lhiggie]

Pieter,

Thank you, I was unaware of dop previously and have installed sudo and have my users using sudo.

Sudo so far is doing what I need it to do for now.

Again,

Thank you for your assistance!

[lhiggie]

Thanks to Steven and Pieter. They both provided a solution to my problem. Steven with the majority of the fix. Please see his 1st and 2nd answer.