NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/unix/sysv386/13968

Internet Message Format | 1992-09-02 | 4.6 KB

Path: sparky!uunet!wupost!tulane!mgse!marks
From: [e-mail] (Mark Seiffert)
Newsgroups: comp.unix.sysv386
Subject: Re: SUMMARY: Re: Questions about MAS90 from SOA
Message-ID: <[e-mail]>
Date: 3 Sep 92 04:30:44 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: mgse
Lines: 86

In article <[e-mail]> [e-mail] (Marc Unangst) writes:
|In article <[e-mail]> [e-mail] (bill davidsen) writes:
|>  I included this in my response to you, perhaps you missed it:
|
|No, I didn't miss it.  And I appreciate the suggestion.  However, I
|evaluated it and found it unsuitable for what I'm trying to do.
|
|>Have people login as themselves then do a "su - mas90" to access the
|>database. That way only the mas90 account has to be able to get at the
|>data, and you can use the mas90 program itself as the login shell, or
|>use a secure login shell which can start mas90. That seems to eliminate
|>most of the problems you mentioned.
|
|It may eliminate the problems I mentioned, but it creates a host of
|new ones.  First and foremost is the password for the "mas90" account.
|If I set things up so that there is a password for mas90, then the
|users now have to remember THREE passwords: the password for their own
|account, the mas90 password, and the password for their MAS90 user-id.
|I have enough trouble getting people to remember the first password
|and the last without writing them down, and you want me to add a third
|password?  But if I don't have a password, I open up a big security
|hole.  Yes, it's about the same as allowing people to run MAS90
|directly as themselves, except that now they have access to the MAS90
|program files and such without a password, instead of just the data
|files.  What if they convince MAS90 to let them spawn a shell, or edit
|a file?

What is wrong with allowing MAS90 to be ran by the users directly.  I
thought mas90 shipped with /bin/soa to run MAS90 and MAS90 is capable of
providing it's own security, they may be able to use their own passwords
if they are short enough.

The problem with spawning a shell is valid, maybe you can run MAS90 from
rsh instead of sh or use chroot if you are that worried about users getting
shells, but if you are that worried about users getting a shell and removing
files, you may want to reconsider letting them into the computer at all.

|
|>You could also use a command sutuid root which does a seteuid() and then
|>starts mas90, I bet that will work, too.
|
|I tried that, as well as making bbx2 SUID mas90.  Unfortunately, MAS90
|was not written to be SUID, so it does not handle things like real
|vs. effective user-id when checking permissions.

But bbx2run does. It sets umask as high as it can and then sets the user
id to the real user id and then execs bbx2.

|
|The basic problem seems to be that MAS90 was coded without regard to
|use in a networked environment, or use on a machine that is also used
|for other applications and by non-MAS90 users.  MAS90 works without a
|hitch, I'm sure, if that's the only thing you're running on the
|machine and everyone has a hardwired serial connection with a Wyse-60
|emulator or something.

The bbx interpreter does not work well in networks from what I have heard,
especially across NFS because it is unable to get file locks. I have not
played with mas90 across a network, but a co-worker has using coconet.
MAS90, or rather bbx, is able to co-exist with the lp spooler system, and
with word perfect and it's printer requirements. I works with Progress,
Lotus, Foxbase, SCO Pro and other programs running at the same time. You
may want to get on compuserve and checkout the BASIS forum, you seem to
have problems and questions regarding bbx rather than MAS90. Play with
the MAS90 security and when setting up printers to talk directly to
the printer port, make sure that you use lock files in config.bbx (a bbx
function, not mas90) and make sure that you add the lock files to the
printer interfaces. The company I work for does program development
and has installations on PC-DOS, Novell, SCO Xenix/Unix, BULL BOS,
Sperry 5000's, RS/6000s and even a pair of HPs (320 & 350?) with NFS.


Mark Seiffert

|
|--
|Marc Unangst                | Real men don't make backups.  Real men never
|[e-mail]   | accidentally delete files that they're going
|                            | to need later.


--
Mark Seiffert,  Metairie, LA.
uucp:           rex.cs.tulane.edu!mgse!marks or rex!mgse!marks
bitnet:         [e-mail]
internet:       [e-mail] or [e-mail]