SEO

Brian K. White wrote:

> >>> On 27 Mar, 13:44, "andrewm...@gmail.com" <andrewm...@gmail.com> wrote:

> >>>> When they go to hit 'w' for the who command, it only shows them as
> >>>> logged in. I'm not sure why. Could you please help?

> As for why users who run w can't see other users?
> You said you set up the kill command successfully, but then complained
> that the w command doesn't work.
> If you need them to be able to run w with root privs, then you have to
> set up the w command the same way.
>
> When I run w as a user I see everything, but, w (and who, and finger)
> gets much of it's info from /etc/utmp
> /etc/utmp is just a file that various programs update when users
> login,logout, or issue commands.
> It can become out of sync with reality or corrupt to a small or large
> degree lots of different ways.
> So, any time any of the utmp/wtmp/utmpx/wtmpx reading commands acts
> at all funny, one easy step to try is to reset those files. The
> only difficulty is ideally you should reboot or at least switch to
> single-user mode to do it and then immediately reboot afterwards back
> to normal mode.
>
> cd /etc
> >utmp
> >utmpx
> >wtmp
> >wtmpx
> shutdown -g0 -i6 y
>
>
> Another possible hint comes right from "man w"
> ---snip---
> Authorization
> The behavior of these utilities is affected by assignment of the
> mem authorization On systems installed with ``high'' security,
> this is usually reserved for system administrators. If you do not
> have this authorization, the output will be restricted to data
> about your activities. Refer to ``Using a secure system'' in the
> Operating System User's Guide for more details.
> ---snip---
>
> So, for me, setting up w in asroot with root privs, and adding w
> authorization to a user, and having that user run "/tcb/bin/asroot w"
> made no difference, but perhaps on your box it will. All my boxes are
> installed with the default security.
> You may want to do the same with ps.

If `w` and `ps` don't show other users' jobs, it's because the user
running them doesn't have "mem" privilege. The correct repair for this
is not to force the entire command to run as root!

Give the users "mem" privilege.

Omitting "mem" is one of the differences between the "high" security
profile and all the others.

I don't remember right now how to change this, not doing day to day OSR5
admin lately, but it's easy. `scoadmin user`, maybe.

You can either individually give out "mem", change the entire system to
a different security profile, or merely change the systemwide default
for "mem" while leaving the rest of the "high" security profile in
place.

You might still have to individually tweak some users if you changed any
of their other privileges in the past: I think in that case it changes
the user's security record from just saying "use the system wide default
settings" to a copy of the then-current defaults with your specific
changes applied to it. Then when you change the systemwide default,
those individually changed users are not affected.

>Bela<