Obtaining root in SCO 2.1

Obtaining root in SCO 2.1

Post by David Nag » Sun, 17 May 1998 04:00:00



Hello all,

I'm new to the UNIX world comming from an NT background.

One of my clients running SCO 2.1 has a problem. He has forgotten the root
password.

This is causing some serious problems (obviously). A file needs to be
deleted that root owns (the file keeps growing in size and crashes the
system).

Can anyone give me any ideas on a way to get root access or at least change
file ownership? Basically I need to break into this box.

I have access to an account that almost has root access BTW. I figure there
must be a known issue in an older version of SCO such as this.

Also, can anyone tell me if SCO 2.1 can support IDE hard drives and
CD-ROMs??

Thanks, repy by e-mail if possible.

Dave Nagy

 
 
 

Obtaining root in SCO 2.1

Post by Marco Bine » Mon, 18 May 1998 04:00:00



> Hello all,

> I'm new to the UNIX world comming from an NT background.

> One of my clients running SCO 2.1 has a problem. He has forgotten the root
> password.

> This is causing some serious problems (obviously). A file needs to be
> deleted that root owns (the file keeps growing in size and crashes the
> system).

> Can anyone give me any ideas on a way to get root access or at least change
> file ownership? Basically I need to break into this box.

> I have access to an account that almost has root access BTW. I figure there
> must be a known issue in an older version of SCO such as this.

> Also, can anyone tell me if SCO 2.1 can support IDE hard drives and
> CD-ROMs??

> Thanks, repy by e-mail if possible.

> Dave Nagy

 Hi

this is part of FAQ of Steve Dunn SCO, perhaps helps:

 ____________________________________________________________________________

  How do I reset the root password if I forget it? (part 1)
  =========================================================

  This procedure will work for Xenix, and for Unix as well if you are using a
  very relaxed security level (one which stores encrypted passwords directly
  in /etc/passwd). If you're using a higher security level on Unix, look for
  part 2 below.

  Boot the system from your emergency boot diskettes (if you didn't make these
  and keep them up to date, shame on you, but you should be able to use N1/N2
  instead, and see the entry on crashing out of these diskettes below). Next,
  mount /dev/hd0root /mnt; this will mount your hard drive's root filesystem
  on /mnt. Edit /mnt/etc/passwd. The first line will be your root line, such
  as

  root:encryptedpasswordgoeshere:0:0:God,Everywhere:/:/bin/sh

  Edit out the encrypted password (don't touch anything else!) so that the
  line reads something like

  root::0:0:God,Everywhere:/:/bin/sh

  Save the file and shut down. Reboot from the hard drive. Your root password
  has now been removed, and you can reset it normally.

  ____________________________________________________________________________

  How do I reset the root password if I forget it? (part 2)
  =========================================================

  This is another procedure involving manually editing files, and is specific
  to SCO Unix 3.2v4.0 through 3.2v4.2. The location of the encrypted
  passwords depends on the security settings. Look in /etc/passwd,
  /etc/shadow, and /tcb/files/auth/r/root; one or more of these will be used
  depending on how you have security configured. Follow the procedure in part
  1 above; instead of editing /etc/passwd, edit the appropriate file(s) from
  the above list, and delete the encrypted password field. Note that
  formatting is critical; while you can delete the contents of the field, you
  must not remove separators, and making seemingly minor errors such as
  leaving blank lines can cause problems. Save, shut down, and reboot. C2
  security will complain about what you've done; to make it happy, run
  /etc/fixmog. You may also want to run /tcb/bin/integrity and /etc/tcbck.

  ____________________________________________________________________________

  How do I reset the root password if I forget it? (part 3)
  =========================================================

  This procedure will work for any variant of SCO Xenix or Unix. As above,
  boot from your emergency boot diskettes and mount /dev/hd0root /mnt to gain
  access to your hard drive's root filesystem. Now, run /mnt/bin/chroot /mnt
  "/mnt/bin/passwd root" (check the chroot man page for more info on how it
  works). As before, shut down and reboot. It has been reported that on
  3.2v4.2 (and possibly others), this must be done in two steps:
  /mnt/bin/chroot /mnt "/bin/su root", followed by passwd.

  ____________________________________________________________________________

Marco

 
 
 

1. Strange I/O errors from SCO/ARCserve 2.1.0e

I will appreciate any suggestions regarding where even to start to look
for solution to the following problem. Thank you!

Relevant HW & SW:

SCO OpenServer 5.0.2 on IBM PC Server 320;
no patches applied ( can you believe this? :);
SCO ARCserve/Open v2.1.0e with Changer Option;
Exabyte EXB-10e tape changer (10 slots, EXB-8505 tape drive);
Adaptec AHA-2940UW with 1 internal HD (ID 0), tape changer (IDs 3 & 4),
CD ROM (ID 5) and another internal DAT tape (ID 6).

Problem:

rarely (2-3-4 times per month), on a random basis, the nightly backup
performed by ARCserve fails with these messages in ARCserve's activity
log:

Jun-19 20:10:22    370 E1036 Failed to write data to tape, Unrecoverable
data error
Jun-19 20:10:23    370 E9132 File [/u1/oradata/cage/log02.dbf] is
truncated (2295808 bytes)

After that, ARCserve drops current session and the entire backup
(and proceeds to compare step).

I fail to see any system in when and under what circumstances those
errors occur. It's not like the backup stops always at some particular
file, but still a little bit more often when processing this log02.dbf -
an archive log file of inactive Oracle instance. Sometimes the similar
error, only about reading from tape, appears when comparing files after
the backup part was successfully completed. The system on which ARCserve
runs sits idle during the backup hours (no active/logged in users or any
running application processes, except ARCserve, of course).

What's strange is that the only place where those tape errors show up is
the ARCserve activity log: neither SCO's alad nor Cheyenne's chey driver
detects any anomalies, nothing is written to /usr/adm/messages. Even
ARCserve's own tape server (process tapesrv) doesn't report any unusual
conditions in its log. So it looks like ARCserve's aprocess (or maybe
asod?) is the only agent in the entire system that thinks (or knows?)
that the tape drive experiences problems - no other process or OS itself
notices anything special.

Because of that I'm inclined to think that the hardware is OK but
ARCserve software behaves erratically. But that's it, I have no clue
what to do now and where to look. I checked IPC resources usage by
ARCserve and didn't find anything disturbing (SHMMAX/SEMMNI/etc. are set
as recommended for ARCserve).

+----------------------------------------------------------------------+

| UNIX Systems Administrator   )))   WWW: http://ynp.dialup.access.net |
| The Davidsohn Group, NYC    ///    B:(212)208-0129,  H:(718)234-4140 |
+----------------------------------------------------------------------+

2. test for presence of file on remote system / rsh problem

3. SCO Unixware 2.1

4. network/application problems

5. Need Slackware 2.1 color144 root disk image

6. Can one do disk-to-disk copys with Sun hard disks?

7. NFS-Root Problem in Debian 2.1??

8. Lotus Go Webserver Proxy capability

9. Bulk install SCO UnixWare 2.1

10. Wanted -SCO 2.1 Online Data Manager

11. Sco Unixware 2.1

12. SCO UnixWare 2.1 with 3Com 3C905b (Dell GX1+)

13. Req for Help: KDE 2.1 and non-root users on RedHat 7.0