SCO Xenix System Hang

[Dominic Dunlop]

In article <418 at marob.MASA.COM> daveh at marob.masa.com (Dave Hammond) writes:
>>In article <329 at bilver.UUCP> bill at bilver.UUCP (bill vermillion) writes:
>>[...]
>>         .  When a user runs our software, they all login with the
>>same user id which starts executing our own user interface shell
> ^^^^^^^^^^^^
> (problem lies here)
>...
>BTW, unless there is a Real Good Reason for having multiple users with the
>same user-id, it is far more appropriate for security, file management and
>system administration purposes to assign individual user-ids.

Absolutely.  Bill can probably achieve the effect he desires in terms of
file access permissions by putting all of the users of his application
into a single, dedicated group -- let's call it billsapp.  This needs a
line like

	300::billsapp:appuser1,appuser2,appuser3,appuser4

in /etc/group, together with 300 (or whatever group id he assigns) in the
fourth field of the /etc/passwd entry for each of those users.  For example

	appuser3:ecBxt/7Df8qlf:123:300:Bill's third user:/u/app/:/bin/sh

The SCO Xenix mkuser (user administration) tools could help Bill to set
things up in this way, except that, as I recall (can't run it up just now
-- the closest system's sufficiently secure that I don't know the root
password), it does not like assigning a new user to an existing home
directory, an action which is perfectly proper in a case such as this.
So Bill will probably have to do things by hand (SCO, please note).

This done, all files used by the application should be fixed to have write
permission for group.  Directories used for such things as scratch and
spool files need group write permission too.  Often, it's sufficient to do
this set-up by hand as part of installation, as many applications don't
need to _create_ shareable files when they run; they simply need to update
existing shareable files, and to create user-private scratch files.  Where
shareable files must be created -- for example, if one user generates a
print spooling file which can subsequently be reprinted by another user --
the application must create a shareable file.  The best way to do this is
to modify the application so that it explicitly gives a suitable file
permissions mask value to the corresponding creat() or write() call.  To be
absolutely certain of getting a particular set of permissions, whatever the
value of the user's file creation permissions mask (umask), it's necessary
to call chmod() after file creation.  However, it's often sufficient to set
up a suitable umask in the .profile script run by /bin/sh when a user logs
into the system, provided that calls on open() and creat() in the
application specify permissive creation permissions -- typically 0666.
(Most programs, including BASIC, COBOL, and ``fourth-generation'' run-time
systems, do this).  For example

	umask 0660			# read/write for user, group
	PATH=/u/billsbin:$PATH export PATH
	cd /u/billsapp/billsdata
	exec billsapp

in /u/billsapp/.profile will throw any user whose home directory is
/u/billsapp (and whose login shell is /bin/sh) straight into the
application after setting up a suitable file creation mask, executable
search path, and current directory.  My company uses a procedure very like
this to run up an accounting package which we bought in binary form (and so
couldn't modify), and which was very insecure straight out of the box.
(All the permissions were wide-open, so anybody could do anything, whether
they were an accounts person or not.)

The method I've outlined is probably sufficient for most applications.
However, there are times when more sophistication is required -- for
example, the case where an application needs to write a file which can be
accessed only by the application, not even by UNIX shell commands run by
the user who created the file.  In such cases, you need to get involved
with set-group-id programs.  I'd counsel against doing this unless you
really need to, as

  a) They're surprisingly difficult to get right (AT&T's mail gets it
     right; AT&T's lp gets it wrong); and

  b) It's a good way to write applications which are not easily portable
     between AT&T and Berkeley variants of UNIX (Xenix is in the AT&T camp
     on this issue).

To read further... _UNIX System Security_ by Wood & Kochan (Hayden, 1985,
ISBN 0-8104-6267-2) is a good place to start.

Hope this helps.
-- 
Dominic Dunlop
domo at sphinx.co.uk  domo at riddle.uucp