[net.unix-wizards] unix src vs binary

cottrell@nbs-vms.ARPA (02/08/85)

From: BostonU SysMgr <root%bostonu.csnet@CSNET-RELAY.ARPA>
> I think there is a possibly productive contribution that could come out
> of all these electrons flying by about AT&T source policies. It just hit
> me full force as I was left with a few 3B machines with a binary
> distribution on them (the source is in the mail) and now I gotta set
> them up.
> 
> In the old days (less now) DEC would give a binary site for certain
> (most) O/S's quite a few sources, recognizing that this is necessary for
> survival. I think that there are quite a few programs/source modules
> that MUST be supplied with a UNIX distribution for survival. I realize
> a few of these are supplied with SOME distributions, but not enough.
> 
> Assuming somebody from AT&T is listening (or could get the right person
> to listen) maybe someone could collect arguments for certain selected
> sources from us unix-wizards and consider why we are so upset/frightened
> by binary only systems. DON'T JUST START SENDING YOUR ARGUMENTS TO THIS
> LIST, they'll just get lost.
> 
> Sample arguments:
> 
> 	login.c,su.c:	This is the front-line of defense

True, but naive administrators might axually log all attempts to
become super user with the password. If someone who knows the password
makes a typo & the log file is readable by others, variations on a theme
will produce the correct password quickly. The worst defense is a good
offense (for the bad guys).

> 	passwd.c:	for any system. I should be able to
> 			add rules like times of day for certain
> 			uids or secondary/long passwords.

Time of day could be enforced by coding a `shell' program that
checx the time, & only exec's /bin/sh if legal. It could also
require secondary passwords. The path name of the user's desired
shell could be encoded after his name in the gecos field.

> 	getty.c:	This often needs a little customization
> 			to work properly in a given environment.
> 
> 	init.c:		same.
> 
> 	All accounting summary software: C'mon, it isn't likely
> 			to be exactly right for my site.
> 
> 	A few drivers:	tty.c and friends for a little customization.
> 			A disk and/or tape device for examples if
> 			your binary claims to support addition of
> 			user drivers (an LP driver wouldn't hurt.)
> 
> I think these are reasonable arguements, at least maybe a package of
> these could be sold inexpensively and unbundled from full source. I
> am not sure I really need the sources to, eg., cat.c to support my
> system.

Sorry for the nitpix. I agree with you in principal. Think of my
comments as helpful hints where applicable. BTW, why do you always
logon as root, rather than doing su when you need to? Even I don't
trust myself as root for too long. Bad practice?
*/

Roger Hale <roger@ll-sst.ARPA> (02/08/85)

From: cottrell@NBS-VMS.ARPA
(Replying-to: BostonU SysMgr <root%bostonu.csnet@CSNET-RELAY.ARPA>)
> Time of day could be enforced by coding a `shell' program that
> chec[ks] the time, & only exec's /bin/sh if legal. It could also
> require secondary passwords. The path name of the user's desired
> shell could be encoded after his name in the gecos field.

I wouldn't use the gecos field; it's already overused.  Berkeley
keeps a finger database in the position you mention.  (Version 7
suggests GCOS job number, box number, optional GCOS user-id *<8-) .)
I would look for a .shell file in the user's home directory and
accept the name therein if it's on my list of ``trusted shells''
(which I might compile in or read from a ``secure'' file in /etc).

Yr obedt svt,
Roger Hale (roger@ll-sst)

cottrell@nbs-vms.ARPA (02/12/85)

/*
From Roger Hale replying to...
> From: cottrell@NBS-VMS.ARPA
> (Replying-to: BostonU SysMgr <root%bostonu.csnet@CSNET-RELAY.ARPA>)
> > Time of day could be enforced by coding a `shell' program that
> > chec[ks] the time, & only exec's /bin/sh if legal. It could also
> > require secondary passwords. The path name of the user's desired
> > shell could be encoded after his name in the gecos field.
> 
> I wouldn't use the gecos field; it's already overused.  Berkeley
> keeps a finger database in the position you mention.  (Version 7
> suggests GCOS job number, box number, optional GCOS user-id *<8-) .)
> I would look for a .shell file in the user's home directory and
> accept the name therein if it's on my list of ``trusted shells''
> (which I might compile in or read from a ``secure'' file in /etc).
> 
> Yr obedt svt,
> Roger Hale (roger@ll-sst)

Okay, don't use gecos. Use .shell in his home directory (if it exists)
or default to your favorite of sh or csh. BUT, there is no reason to
quibble about his choice of shells. They need not be trusted. As long
as you exec it the same way with the same uid, gid, & file descriptors
as would normally happen, there is no reason to limit his choice. He
can't do anything those trusted shells can do or something else is amiss.
*/