Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!mailrus!tut.cis.ohio-state.edu!rutgers!uwvax!oddjob!mimsy!jds From: jds@mimsy.UUCP (James da Silva) Newsgroups: comp.os.minix Subject: Re: 1.3a/b update, comp.sources.minix? (and becoming root) Keywords: newsgroup, problems, rijksdaalder Message-ID: <13759@mimsy.UUCP> Date: 27 Sep 88 18:51:38 GMT References: <2545@sultra.UUCP> Reply-To: jds@mimsy.umd.edu (James da Silva) Organization: University of Maryland, Department of Computer Science Lines: 70 In article <2545@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: > >The main reason I'm posting this, is I was thinking today, about the >possibility of a new newsgroup called 'comp.sources.minix', so that we >could separate the comments (like this one) from the "real stuff". I have a >hard time going through the archives looking at subject fields, and not >knowing if they are notes of problems or actual code changes. At this stage, >I thought I'd open the topic for discussion. If it has been opened before, >then excuse the repetition. As far as usage is concerned, the group would >have a lot more activity than some of the other subgroups I see there (no >names mentioned!). This has been brought up before, but not resolved. It may be that a moderated source group could make life easier for people searching for things, but who would moderate the group? And there are lots of postings that contain tips or small patches along with other stuff. These are as valuable as the large source postings, and should be archived as well. The real problem, in my opinion, is that the archives, including my archive, index the articles by subject line. The subject lines don't always tell you enough about the article. When I edit the archive for a month, I try to group related articles together, rather than putting them in cronological order, but even that is not enough. There's no easy solution, as the Archive maintainers are already doing a lot, they can't be expected to become Editors as well. Perhaps the best thing we can hope for is for people to be careful to write a descriptive subject line when they are posting source, a bug report, or something of lasting value. >I figured out how to start the system sans documentation, and everything >was fine until the RAM disk loaded, then I was presented with "login:". >Ok, so I've been around distribution tapes long enough, I typed 'root'. I >figured the password field would be blank! Boy, was I wrong. I was >prompted for a password, and tried ALL the obvious with no luck! Now what! >I mean, in a situation like this, what does one do? Order the manual and >wait another six weeks? No. I loaded the root filesystem disk into >MS-DOS, and using the debugger, wrote a quick program to load each track. >Then, i dumped out the data, looking for something resembling a /etc/passwd >file. I found it, patched the first byte of the password to ':', meaning >that there is no password set, wrote the block back out to disk, and >rebooted. Hey presto! I didn't ask me for a password. One of the first >tasks I had, as root, was to change the password. It wasn't until I found >the reference manual locally, that I found out what the original password >was!!! I admire your persistence. There's an easier way to do it: Minix has login in /usr/bin. If init can't find /usr/bin/login, it gives you a root shell. So, when Minix tells you to put the /usr disk in, ignore it and just hit RETURN. Boom, root shell. So everyone, put away your debug disks! For those who prefer the front door, the root password is 'Geheim' on the distribution disks. >I guess that qualifies me for a rijksdaalder (whatever that is)!! Well.... I think we both cheated. No operating system can really protect against someone using a debugger/monitor to hack the distribution disks or tapes then loading them. This isn't really a hole in the OS security. Also, I wonder what 'real' unix init does if it can't find getty or other crucial files at boot time? In general, if a knowledgeable user has access to the physical machine, she can break in sooner or later. - Jaime ---------------------------------------------------------------------- usenet: uunet!mimsy!jds James da Silva internet: jds@mimsy.umd.edu "Stand on each other's shoulders, not on each other's toes."