SCO UNIX adding users and read(), truncating filenames

[Roger Knopf 5502]

NOTE: this is an extremely long posting, but I think it contains much
of interest to many net readers.

In article <1990Jun6.202656.14890 at dircon.uucp> sys0001 at dircon.uucp () writes:
>First of all, I want to several users to share a home/login directory.
>However, in the 'sysadmsh', when I try to enter the same home directory
>for more than one user, I get an error: "Home directory already exists".
>The program will not let me add the user until I change the home dir
>to one which doesn't already exist. In fact this occurs with all logins,
>whenever the home directory already exists. Is there any way of overcoming 
>this?

Let me first say that the advice I am about to give may, if followed,
lead to less than C2 level trustedness on your systems. If you follow
it, I assume you don't care about C2. Caveat administrator.

This is correct, sysadmsh will not allow users to share home directories.
That doesn't mean that it can't be done, though - there is nothing that
will break if you do this, although some programs may complain about
it. There are three approaches you can take to accomplish this:

1. Edit the home directory after you have created the account. Remember
   to change it in both /etc/passwd and 
   /tcb/files/auth/<login first initial>/<loginname>. Ugly, nonportable
   but it works. Example: my entry is /tcb/files/auth/r/rogerk. The 
   structure of the entry is self-evident (didn't professors in
   college say that when they either didn't know or didn't feel like
   explaining?) but be sure not to change anything but the home directory.

2. Use /tcb/bin/addxusers. This isn't exactly user friendly but it will
   add a user for which the home directory exists (although it will
   complain about the fact that they don't own it). It also means that
   you have to come up with an encrypted password to put in the input
   file (for those not familiar w/addxusers, it takes a Xenix passwd
   file as input). This can be done by a) using a standard encrypted
   password to start with, perhaps the null password, or b) writing a
   program to encrypt the password. If you can do the latter, then
   you may also be able to:

2. Write your own program to make new accounts. There are library calls
   to write new /etc/passwd (putprent) and tcb entries (putprpwent).
   The latter is not easy to use and I hope to have a good example
   program soon. It is easy enough to modify our standard /usr/lib/mkuser
   scripts to make accounts or write your own (make a directory,
   copy in a .profile or .login/.cshrc or whatever, chown to the user).
   If you want C2, be sure to check authorizations before creating or
   changing a password entry and write an audit record on all failures
   or unauthorized attempts.

>Also, is there a command-line interface method of adding users. I've got a
>batch of several hundred which I want to add in one go (from a Xenix system).
>It would be handy if I could add them in one go, setting their ID number, 
>group, login shell and home dir in a batch file. Any ideas on how this could 
>be done? I'd like to do this in a way which keeps the 'tcb' C2 security files
>up-to-date as well.

addxusers is exactly what you want. There is one on your system although
there is a new on available in the SLS unx199 (which also has other nice
security fixes/relaxations/sysadmin improvments. Get it from support).
I don't know if there were any bugs in the older one or any new features
added since I never used the older one, but you should have unx199 anyway.
Its in /tcb/bin and that probably isn't in your PATH environment variable.
 
>The second problem I've come across is that when I run a program from my
>Xenix system under UNIX, it drops out (no error message or anything) back
>to shell whenever it comes across a call to the C read() function to read
>a record from a small database file into a structure: 
>ie something along the lines of read(fd, &rec, sizeof(struct rec)).
>It seems not to even get to the line following the read(), so I can't test
>for return values.
 
C programs don't automatically print error messages, you have to program
for it. Nor do they return status to the shell; that is done by exit().
Try this:

	int nb;

	if ((nb = read(fd, &rec, sizeof(struct rec))) != sizeof (struct rec)){
		if (nb > 0)
			/* do end-of-file processing */
		if (nb < 0) {
			perror("read");	/* print standard error message */
			exit(-1);	/* return a status to the shell */
		}
	}

This may not be your problem, but your tiny program fragment and 
comments leads one to believe that these niceties may have been
overlooked.

>This behaviour is exhibited wherever read() is called, apparently after the
>relevant file has been opened with O_RDRW|O_SYNC. I've tried recompiling 
>using the SCO UNIX dev system (with the -xenix flag) but no go. The program 
>still drops out without any error message. Help/ideas/comments much 
>appreciated! (by the way, this program currently works fine under Xenix 2.2).
>If I remove the O_SYNC flag then the program seems to work OK.

Assuming that you are using a current (read: not beta) OS, this sounds
like a bug we should know more about. It would help to make a small
program that can reproduce it with and send it to tech support (or
me, I'll forward it to the appropriate people).
 
>Finally, can anyone let me know what the fix/patch is to switch off the
>long filename truncation errors, which are getting to be a real pain.

I think that this should be in Conor's frequently asked Q&A file. It
is definitely on our SOS system that is available to all supported
customers (find out more by emailing sco!support). For your benefit and
the general interest of net readers, here it is:

----------------------------------------------------------------------------
Eliminating errors caused by file names longer than 14 characters.

KEYWORDS: file name long file unix adb /etc/_fst patch kernel ETRUNC nami 14

RELEASE:  SCO UNIX System V/386 Release 3.2.0

PROBLEM:  Attempts to create a file with a file name longer than 
	  14 characters fails with an error rather than truncating 
	  the name to the 14 character limit.

CAUSE:    This functionality was added for conformance to the POSIX 
	  standards.

SOLUTION: The following patch can be applied to the UNIX kernel so 
	  that long file names will be silently truncated.  Bring 
	  your system into System Maintenance mode and enter the 
	  following commands:

		# /etc/_fst -w /etc/conf/pack.d/s5/Driver.o
		* $x
		* s5namei+0xab?w 0x0feb
		s5namei+0xab:     0xc74 =  0xfeb           [response from _fst]
		* $q

		# /etc/_fst -w /etc/conf/pack.d/xx/Driver.o
		* $x
		* xxnamei+0xa6?w 0x0feb
		xxnamei+0xa6:      0xc74=  0x0             [response from _fst]
		xxnamei+0xa8:      0x3d83= 0xfeb           [response from _fst]
		* $q

	  Relink your kernel by moving to the directory /etc/conf/cf.d 
	  and entering the command /etc/conf/cf.d/link_unix.  You must 
	  reboot your system for the change to take effect.

-- 
Roger Knopf                                      <standard disclaimer applies>
SCO Consulting Services
uunet!sco!rogerk  or  rogerk at sco.com         "...and he's got bare feet, too."
408-425-7222 (voice) 408-458-4227 (fax)           --Charley Watkins