NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/linux/21873

Text File | 1992-12-28 | 6.1 KB | 151 lines

Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!drycas.club.cc.cmu.edu!ghod
From: [e-mail]
Newsgroups: comp.os.linux
Subject: Re: xdm without rc.local and other stuff
Message-ID: <[e-mail]>
Date: 28 Dec 92 00:38:58 -0500
References: <[e-mail]>
Organization: Carnegie Mellon Computer Club
Lines: 140

In article <[e-mail]>, pmacdona@sanjuan (Peter MacDonald) writes:
> I am working on fixing some of the most commonly posted problems
> or requested features for the next SLS.  One of them is xdm.
> I have recompiled it, and am trying to find a way to start it
> without putting it in rc.local (ie, from the command line).
> Can someone offer up any help?
>
I think I can. Someone posted the following suggestion for getting xdm running
from the command line *without* the -nodaemon flag, prior to the release of
0.99:

Invoke xdm as follows:

skynet{1}# xdm; exec < /dev/tty8; exec > /dev/tty8

(Note that I think you can substitute tty8 with any tty that doesn't currently
have a getty running on it. Wonder what would happen if you used /dev/null?)

I've tried this on my own system and I've veriffied that it works (I've got
0.99 pl1 going). This is a kludge, of course: just plain xdm -nodaemon should
still work, but it doesn't. I'm

> Xdm, xlock etc had to be recompiled because of shadow passwords.
> Effectively, these programs, plus any others that let new users
> into the system (ie, check passwords), must now be suid root.
> Ditto for ftpd.

[stuff deleted]

> suid root.  One caveat is that xlock had to be changed to use:
>
>     pw=getpwuid(getuid())
>
> instead of
>
>     pw=getpwnam(cuserid(NULL))
>
> This because of the suid.  If anyone thinks this is a security
> problem, let me know.  Xdm need no source changes, other than
> to delete a few "extern char *crypt()" defs.

Heh... Yup, I recognize that problem. :) I re-compiled xlock myself (I'm an
impatient sod) and was quite surprised when I ran it the first time as
a normal user and was prompted to enter the root password. I don't think
there is a security problem inherent in running xlock setuid root, since I
can't see any way for someone to trick xlock into actually modifying the shadow
password file, or creating any other files. Unless, of course, it core
dumps. :)

BTW, I went and got the source to xdm from my local X11R5 distribution and
modified it (as well as the aforementioned xlock -- ftpd is next on my list)
for shadows password myself, but what I did was to write a small add-on module
called getshadow.c to implement a sort of kluged up getspnam() function.
Actually, it's much simpler than getspwnam() -- you just pass it a username
and it returns a pointer to a string containing the encrypted password for
that user:


#include <stdio.h>
#include <string.h>
#include <unistd.h>
#define SHADOW "/etc/shadow"


char *getshadow(user)
char *user;
{
        FILE *sfile;
        char entry[512];
        static char password[13];

        sfile = fopen(SHADOW,"r");
        while(fgets(entry,sizeof(entry),sfile)) {
                if (strstr(entry,user)) {
                        strncpy(password,strchr(entry,':')+1,sizeof(password));
                        fclose(sfile);
                        return password;
                        }
                }

        fclose(sfile);
        return NULL;
}

Before you say it, there's two things wrong with this code. It looks for the
first occurence of a ':' in the line it reads from /etc/shadow and just
assumes that the next 13 characters are the encrypted password. Most of the
time this is true, but the password comparisson will fail if the password
field is empty (::).

(In a way, this is good since it disallows logins to users with null passwords,
like sync, but it's still sloppy. In retrospect though, it seems to me that the
new passwd program still generates a 13 character encrypted mess even if you
just type <RETURN> as the password. :)

Second, it assumes the encrypted password is only 13 characters long, which I
have noticed is not always so (but I think it should be). I tend to use a
password for my user account that is actually 9 characters long. Normally,
most unix password/login programs only use the first 8 characters of the
cleartext password and ignore the rest, but for this user account with a 9
character cleartext password, I get this:

wpaul:tPiPVlgffntkIYicTiVpkprw:8392:0:10000

The password field here is 24 characters long. Nobody else seems to have
mentioned anything about this before, so I don't know if it's a common
occurence or if it's just me.

[stuff about next SLS release deleted]

That reminds me: I have a question for you about the current SLS release.
Exactly what version of the kernel & which options were used for the a1
disk? I ask because I ran into a really strange problem the other day: I've
got a friend with 486 33 and a Data Technologies DTC 3292 SCSI adapter (and
a Seagate ST3283N drive). The kernel on the a1 disk seems to boot & recognize
his SCSI setup correctly, but the boot disk generated by the doinstall script
doesn't. I rigged the a1 disk to serve as his boot disk, but I can't keep it
like that since the a1 disk doesn't have TCP/IP in it. In other words, the
kernel that supports his drive doesn't have networking, and the kernel that
has networking doesn't support his drive. Catch 22. This means he can't run X.
The boot messages from the a1 disk say 0.98 pl5 49 (I think), and I went and
got the sources to 0.98 pl5 and made him a new kernel (which I won't get to
test for a few days) but I'm not convinced it's going to work. I would have
thought that the SCSI drivers in the 0.99 kernel would have worked, but they
flatly ignore the presence of his host adapter. Meanwhile, the same 0.99 kernel
tested fine on an Adaptek 1542. I *told* him to get an Adaptek, but noooo.....
Anyway, if anyone knows why it is that the 0.98 kernel likes his SCSI stuff
and the 0.99 doesn't please respond.

-Bill Paul

[e-mail]   or   [e-mail]
(Or, in an emergency, [e-mail])



>
> Peter.
> [e-mail]
>