From: Darren Dunham on
Anoop <anoopkumarv(a)gmail.com> wrote:
> But why is the ps even trying to touch /tmp? And that too create files
> as root. IMO not very secure. Or maybe there is a completely diff
> use / view to this..

It's just how the /usr/ucb/ps command worked for years. I've never
investigated the reason for it, but the file is created when it runs.

--
Darren Dunham ddunham(a)taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
From: Anoop on
On Feb 20, 3:51 pm, Darren Dunham <ddun...(a)redwood.taos.com> wrote:
> Anoop <anoopkum...(a)gmail.com> wrote:
> > But why is the ps even trying to touch /tmp? And that too create files
> > as root. IMO not very secure. Or maybe there is a completely diff
> > use / view to this..
>
> It's just how the /usr/ucb/ps command worked for years. I've never
> investigated the reason for it, but the file is created when it runs.
>
> --
> Darren Dunham ddun...(a)taos.com
> Senior Technical Consultant TAOS http://www.taos.com/
> Got some Dr Pepper? San Francisco, CA bay area
> < This line left intentionally blank to confuse you. >


So in our case it is hampering our work. Because the /usr/ucb/ps
command writes something into /tmp which automatically gets root
ownership, we cannot delete the created files. This eventually fills
up /tmp and when other processes need /tmp for whatever, they just
fail coz there is no disk space available on /tmp...

Is there any workaround? I cannot use /usr/bin/ps or psgrep as they do
not provide the same information we need... Can I tell /usr/ucb/ps to
write this file elsewhere or not write it at all.. ? Just hoping!

Thanks so much.
Anoop

From: hume.spamfilter on
Anoop <anoopkumarv(a)gmail.com> wrote:
>>>>>>>>Is /usr/ucb/ps setuid?
>
> How do I find that out?

"ls -l". ie: "ls -l /usr/ucb/ps".

Seeing the permissions on /tmp/ups_data would be helpful, too. As well as
the output from "id".

--
Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
From: hume.spamfilter on
Anoop <anoopkumarv(a)gmail.com> wrote:
> Is there any workaround? I cannot use /usr/bin/ps or psgrep as they do
> not provide the same information we need... Can I tell /usr/ucb/ps to

I'd say the workaround is to figure out why /usr/ucb/ps on your system is
broken, and fix it. What you're describing is not the utility's normal
behaviour.

--
Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
From: Anoop on
On Feb 20, 4:27 pm, hume.spamfil...(a)bofh.ca wrote:
> Anoop <anoopkum...(a)gmail.com> wrote:
> > Is there any workaround? I cannot use /usr/bin/ps or psgrep as they do
> > not provide the same information we need... Can I tell /usr/ucb/psto
>
> I'd say the workaround is to figure out why /usr/ucb/pson your system is
> broken, and fix it. What you're describing is not the utility's normal
> behaviour.
>
> --
> Brandon Hume - hume -> BOFH.Ca,http://WWW.BOFH.Ca/


Here are the outputs:
$ alias ll='ls -ltr'
$ ll / | grep tmp
drwxrwxrwt 20 root sys 12597 Feb 20 16:41 tmp
$ ll /usr/ucb/ps
-r-xr-xr-x 37 root bin 5256 Jan 5 2000 /usr/ucb/ps
$ id
uid=45844(wlitid) gid=7964(gwlitid)
$ ll /tmp | grep ups_data
$ file /usr/ucb/ps
/usr/ucb/ps: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
$ /usr/ucb/ps -v
ps: rename("/tmp/ps.XtaG3j","/tmp/ups_data") failed, Permission
denied
ps: Please notify your System Administrator
PID TT S TIME SIZE RSS %CPU %MEM COMMAND
5052 pts/8 O 0:00 3984 3632 0.2 0.1 /usr/ucb/ps -v
4353 pts/8 S 0:00 1912 1416 0.1 0.0 -ksh
$


/tmp does have the trailing t - is that the setuid??

This is actually a client machine - we need to maintain our
application on it only. So we do not have root access.
Also I will not be able to figure out what if anything is wrong with /
usr/ucb/ps. But I can let the sys admins know that this ps command
needs to be fixed somehow..

Thanks anyways.
Anoop

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Patch Downloads on Solaris 10 x86
Next: seaport absent