[SunHELP] strange problem

[Angela Pardo]

thanks everyone... the machine has definitively been rooted, that was one of
my theories since I've noticed some important executables had the wrong
sizes, but my co-sysadmin had me convinced it was some sort of file system
failure...

anyways thank you all

Angela
-----Original Message-----
From: Nicholas Dronen [mailto:ndronen at frii.com]
Sent: Friday, March 30, 2001 1:19 PM
To: sunhelp at sunhelp.org
Subject: Re: [SunHELP] strange problem


Perhaps someone hacked the box and installed their own
ls(1) command.

# which ls

If it turns out that the ls in your path is other
than /bin/ls or /usr/bin/ls (which are hard links
to the same file), then the next step won't help
you.

# pkgchk -p /usr/bin/ls
# pkgchk -p /bin/ls

If the attributes of the file don't match the attributes
in /var/sadm/install/contents, someone might have hacked
the box.  On the other hand, a non-dodo hacker can cover
his tracks, so this method isn't completely reliable.

Another thing you can do is rely on the shell to prove
that you have a bad version of ls(1).  

# cd /tmp
# echo *
i8n ps_data tdsrace ups_data uscreens

If 'echo *' shows the files with "01" in their names,
but ls(1) doesn't, you're probably using a bad ls(1).

Another thing to try is truss.

# truss -tlstat64 ls -l >/dev/null
lstat64(".", 0xFFBEFD78)                        = 0
lstat64("./ps_data", 0xFFBEFCB8)                = 0
lstat64("./uscreens", 0xFFBEFCB8)               = 0
lstat64("./i8n", 0xFFBEFCB8)                    = 0
lstat64("./ups_data", 0xFFBEFCB8)               = 0
lstat64("./tdsrace", 0xFFBEFCB8)                = 0

Mind you, I ran that command on a machine running Solaris 8.
I don't know if ls(1) on Solaris 7 uses lstat64(2), or some
other variation of stat(2) to get file info.  You might
simply want to use:

# truss -vall ls -l >/dev/null

See whether all the files displayed by 'echo *' show up
in one or more system calls in the truss output.  Finally --
and I hope you're still with me :) -- if Solaris 7's truss
supports library tracing, do

# truss -u:: -vall ls -l 2>truss.out
# grep 01 truss.out

It's slower and much more verbose but it'll show you
all lines where "01" occurs in the truss output.

Regards,

Nicholas Dronen

P.S. Another fellow from your organization posted a message
to comp.unix.solaris today.  It wasn't as clear about the
problem.  Sorry about my misleading response to him.

On Fri, Mar 30, 2001 at 12:36:49PM -0800, Angela Pardo wrote:
> Hi everyone...
> 
> one of my development servers (Solaris 7) have started experiencing a very
> strange problem and I was hoping someone here might have had seen it
> before...
> 
> pretty much all files with "01" on them (e.g. 01-temp.html or joe01.gif)
are
> not visible.  that is you login to the machine (local shell, telnet, ssh,
> ftp)  and you go to the location where the file is supposed to be but the
> file is just not visible to the user (not even root).
> But!
> 
> somehow our webserver (orion [some weird java based web server] ) and CDE
> file manager can see the files and from some shells, although invisible
you
> can modify, open and even rename the file to something else, so it becomes
> visible again.
> at first I thought this could be some sort of corruption with the file
> system so we created and moved some files to a different hard disk in the
> same machine, but we had the same results.
>  
> I have never seen anything like this before, have any of you?
> 
> Angela
> _______________________________________________
> SunHELP maillist  -  SunHELP at sunhelp.org
> http://www.sunhelp.org/mailman/listinfo/sunhelp
_______________________________________________
SunHELP maillist  -  SunHELP at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/sunhelp