HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.admin
Subject: Re: Choice of portnumbers
Date: 28 Aug 1992 21:54:02 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Aug28.135134.26583@amcnix.amc.uva.nl> wetzels@amc.uva.nl (F.Wetzels) writes:
>But if i want to use one of the 65536-1024 portnumbers for a certain
>application, how can be sure that a conflict will not be created.
>That is: someone else has choosen the same number but implemented for
>a different protocol. How do i know this situation will not happen?
>And, what portnumber should i use?

Conflicts only occur if two servers on the same machine are trying to use
the same port number.  The easiest way to prevent this is to use a port
number database.

Most Unix systems have a file /etc/services, or something equivalent to it.
This file maps symbolic names of application protocols to port numbers.
Pick a port number that's not already listed there and use it.  If you
always use this scheme you'll never get a conflict.  Your application
should use getservbyname(3) to get its port number when it starts up.

If you should ever install a package that has a conflicting port number
hard-coded into it, you can resolve the conflict by changing the
/etc/services entry and restarting your server.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.unix.admin,comp.unix.misc,comp.unix.sysv386
From: cudcv@warwick.ac.uk (Rob McMahon)
Subject: Re: yp (nis) map changes - how do they happen
Keywords: passwd yp nis
Organization: Computing Services, Warwick University, UK
Date: Sat, 29 Aug 1992 13:38:21 GMT

In article <cg51Hktf99@atlantis.psu.edu> barr@pop.psu.edu (David Barr) writes:
>Is yppasswd setuid root?  (It needs to be)

No, it doesn't.  At least not under SunOS 4.x.  Ours isn't, and it works fine.
The security comes from the fact that the request contains the old password.

Cheers,

Rob
-- 
UUCP:   ...!mcsun!uknet!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv@uk.ac.warwick             INET:   cudcv@warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
Newsgroups: comp.unix.admin
From: rvdp@cs.vu.nl (Ronald van der Pol)
Subject: Re: Is there an SVR4 version of "top"?
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Date: Fri, 4 Sep 1992 12:52:05 GMT

mfrost@sword.eng.pyramid.com (Mark Frost) writes:

:I have found that top (the program by William LeFebvre) is an extremely
:useful utility to have.  It has come in handy on a number of occasions on
:our BSD-based platform.

:Unfortunately, I lack such a utility on our SVR4-based platform.  Has someone
:done a port?  I started looking at what's involved and it's way beyond me.

Dell did. See dell2.dell.com (143.166.224.14), directory sources/V2.1.
Sources and binaries are included in their SVR4 port.

-- 
		Ronald van der Pol    <rvdp@cs.vu.nl>
From: rouilj@dl5000.bc.edu (John P. Rouillard)
Newsgroups: comp.unix.admin
Subject: Re: Prevent user from editing /etc/passwd
Date: 23 Aug 92 22:15:13 GMT
Organization: Institute for Space Research, Boston College


Don't forget to nuke the environment (especially on Suns) if you use
sudo, or op to provide a restricted set of comands to run.  If you
don't nuke the environment, (or at least the LD_* environment
variables on Suns) you are effectively providing full root access to
that user.


-- John
Xref: sparky comp.unix.admin:4693 comp.unix.questions:10402 comp.unix.shell:3642
From: shah@fnsony.fnal.gov (Hemant Shah)
Newsgroups: comp.unix.admin,comp.unix.questions,comp.unix.shell
Subject: Re: How to prevent a large core-dump
Date: 26 Aug 92 17:49:04 GMT
Reply-To: shah@fnalb.fnal.gov
Followup-To: comp.unix.admin
Organization: Fermi National Accelerator Laboratory, Batavia, IL

In article <1992Aug25.173056.13401@utwente.nl>, soos@math.utwente.nl (Adwin Soos) writes:
|> Hello netters,
|> 
|> A few weeks or even months ago I have read some discussion about the problem
|> of preventing a core-dump. I remember that there were some suggestions on how
|> to prevent that a large core-dump will be made. 
|> This problem is now occurring at our place where someone is writing a large
|> program and in some test-cases there is a core dump for more than 60 Mb.
|> This person is not using this core to debug it so maybe we can just stop the
|> creation of this core for this person.
|> Is there someone who can mail me such suggestions?
|> 
|> Thanks,
|> Adwin Soos
|> 
|> E-mail : A.B.Soos@math.utwente.nl	University of Twente,
|> 					Department of Applied Mathematics,
|> 					Enschede,
|> 					The Netherlands.

If you are using C shell put folowing in your (users) .cshrc file:

limit coredump 0
-- 
-------------------------------------------------------------------------------
Hemant Shah                            | All the opinions expressed are my own
Fermi National Accelerator Laboratory  | and does not necessarily reflect
Systems Integration Group              | those of Fermilab.
E-mail :shah@fnal.fnal.gov             |
 Voice : (708) 840-8071	               | I haven't lost my mind
   Fax : (708) 840-2783                | it's backed on tape somewhere.
-------------------------------------------------------------------------------
Xref: sparky comp.unix.admin:4811 comp.sys.sun.admin:6014 comp.security.misc:1122 alt.security:4227
From: wietse@wzv.win.tue.nl (Wietse Venema)
Newsgroups: comp.unix.admin,comp.sys.sun.admin,comp.security.misc,alt.security
Subject: log_tcp (tcp wrapper) update
Date: 1 Sep 92 12:45:28 GMT
Reply-To: poster
Followup-To: poster
Organization: Eindhoven University of Technology, The Netherlands

This is an announcement of an interim patch for some rough edges that
were left in last June's release. The patch does not introduce any new
features or changes to installation and/or configuration procedures.

The patch has been submitted to comp.sources.misc, and can be picked up
from ftp-win.tue.nl:/pub/security/log_tcp_4.2-to-4.3.Z.

A fully-patched source kit can be found on ftp.win.tue.nl in the file
/pub/security/log_tcp.shar.Z.  The archives on cert.org (in directory
/pub/tools/wrappers) and on ftp.uu.net (in /pub/security) will be
updated ASAP. 

The remainder of this message is an extract of the BLURB file (summary
of fixes and workarounds).

    - Some sites reported that connections would be rejected because
    localhost != localhost.domain. The host name checking code now
    special-cases localhost (problem reported by several sites).

    - The programs now report an error if an existing access control
    file cannot be opened (e.g. due to lack of privileges).  Until now,
    the programs would just pretend that the access control file does
    not exist (reported by Darren Reed, avalon@coombs.anu.edu.au).

    - The timeout period for remote userid lookups was upped to 30
    seconds, in order to cope with slow hosts or networks.  If this is
    too long for you, adjust the TIMEOUT definition in file rfc931.c
    (problem reported by several sites).

    - On hosts with more than one IP network interface, remote userid
    lookups could use the IP address of the "wrong" local interface.
    The problem and its solution were discussed on the rfc931-users
    mailing list.  Scott Schwartz (schwartz@cs.psu.edu) folded the fix
    into the rfc931.c module.

    - The result of % expansion (in shell commands) is now checked for
    stuff that may confuse the shell; it is replaced by underscores
    (problem reported by Icarus Sparry, I.Sparry@gdr.bath.ac.uk).

    - A portability problem was fixed that caused compile-time problems
    on a CRAY (problem reported by Michael Barnett, mikeb@rmit.edu.au).

Finally, a caveat for those who use the optional remote username lookup
feature (RFC 931 protocol).  On some systems, these lookups may trigger
a kernel bug.  When a client host connects to your system, and the RFC
931 connection to that client is rejected by a router, some kernels
drop all connections with that client.  The bug is not in the log_tcp
programs. The patched README file describes how to find out if your
kernel has the bug, and what action can be taken.

	Wietse Venema (wietse@wzv.win.tue.nl),
	Department of Mathematics and Computing Science,
	Eindhoven University of Technology,
	The Netherlands.
Newsgroups: comp.unix.admin
From: norm@bnr.ca (Norm MacNeil)
Subject: Semaphore int value assignment
Originator: norm@bcrks122
Reply-To: norm@bnr.ca
Organization: Bell-Northern Research Ltd.
Date: Tue, 1 Sep 1992 14:12:11 GMT


In the use of semaphores, the union semun is defined as

union semun {
  int val;
  struct sem_ds *buf;
  ushort * array;
} arg;

So if I only use GETVAL or SETVAL, I am using arg.val; however, I cannot seem
to set arg.val to -1 or 0xFFFF to indicate that the value is not yet set.  I don't
want to use 0 because I will be passing back an int of bit flags and 0 would mean,
of course, that no flags are set but any value where more than the number of flags
used is set means that the semaphore is not yet set.

Anyway, if val is an int, why can't I use -1 or 0xFFFF or some other large number?
I don't see any restrictions on the int value in the man of semctl(), etc.

Thanks,
  Norm.

-- 
+-----------------------------------------------------------------------+
 Norm MacNeil                     Phone: (613) 763-7497
 CAD Operation                      Fax: (613) 763-3317
 Bell-Northern Research Ltd.      EMail: norm@bnr.ca (INTERNET)
 #include <disclaimer.std>       "Roller bladers do it in-line!"
Newsgroups: comp.unix.admin
From: singh@r-node.gts.org (Rajendra Singh)
Subject: Last login time not being updated
Organization: Public Access UNIX Information System
Date: Mon, 31 Aug 1992 01:14:45 GMT

I am posting this message because on the machines at school we're
experiencing a problem that the system administrators are a)  too lazy to
fix, and/or b) they don't know how to fix it.

Whenever you do a "finger localuser", the "Last login:" time is always
"Never logged in."  I am sure there's a simple solution on how to fix this
problem, and if anyone knows, please let me know and I will relay the
information to them (i. e. my sys. admins.).

Thanks.
-- 
----------------------------------------------------------------------------
Raj (singh@r-node.gts.org)  If you wish to reply by E-Mail and your response
is greater than 100 lines (of text), then please send your response to:
                    tcomsing@chasm.scar.utoronto.ca
From: pmj@roadnet.com (Peter M. Jansson)
Newsgroups: comp.unix.admin
Subject: Firewalls - How to disable pkt fwd?
Date: 2 Sep 92 13:20:55 GMT
Organization: Roadnet Technologies, Inc.

Hello again,

Thanks to all who responded to my earlier post on setting up a Unix
firewall -- the information was valuable.  I was waiting to post a
summary until my copy of _Practical Unix Security_ by Garfinkel and
Spafford arrived, and after reading the chapter on how to set up a
firewall, I'm left with one question.

The recommended configuration for a choke is that it should not run
/etc/routed and it should be configured to not forward packets from the
one network interface to the other.  I know how to not run /etc/routed,
but I've sweated over my documentation, and I can't find how to turn off
packet forwarding.  Can someone please fill in this last detail for me?
Is there some reason that nobody talks about how to do this?

Thanks again for the help.  I'll post a summary after I get this question
answered, or after a reasonable length of time if I get no answers.

    Pete.
Newsgroups: comp.unix.admin
From: kemnitz@netcom.com (Greg Kemnitz)
Subject: Re: Prevent user from editing /etc/passwd
Date: Sun, 23 Aug 92 19:10:14 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 


How about a crypted shadow passward file? And you are the
only one having the key to decrypt it and knowing where is
the shadow file.

Newsgroups: comp.unix.admin
From: mau@locus.com (Michael Urban)
Subject: Re: SECURITY -- How to list files having suid
Organization: Locus Computing Corporation, Los Angeles, California
Distribution: world,local
Date: Wed, 26 Aug 1992 03:15:17 GMT

In article <1992Aug25.171601.3629@arizona.edu> jjr@ace.ece.arizona.edu (Jeffrey J. Rodriguez) writes:
>I'd like to do a security check on my SPARCstation (SunOS 4.1.1).
>How can I list all files having suid or sgid set?
>With "find -perm" I can only check for exact matches of bits.
>I'd like to just check the suid & sgid bits and not check the
>other permission bits.
>What other security checks should I perform?
>
>Any help would be much appreciated.
>
>Jeff
>rodriguez.ece.arizona.edu

find . \( -perm -2000 -o -perm 4000 \) -print

Newsgroups: comp.unix.admin,comp.windows.x
From: alek@spatial.com (Alek O. Komarnitsky)
Subject: Re: Xterminal-Server ratio wanted
Organization: Spatial Technology, Inc. (Boulder, Colorado)
Date: Fri, 4 Sep 1992 00:23:51 GMT

In article <1992Sep3.022702.13208@news.iastate.edu> john@iastate.edu (John Hascall) writes:
> barmar@think.com (Barry Margolin) writes:
>}tucker@bedford.progress.COM writes:
>}> [...ratio of X-terms to compute servers...]
>And plenty of real-memory.  A rough rule of thumb might be 16+n MBs of
>real memory on your server (n the number of X-terminals you would expect
>to be active at once [all of them in a class/lab, maybe a fourth of those
>in offices]).  Perhaps, 16+2n MBs if your users tend towards big programs.

I'd recommend n >= 4, but it's of course, terribly application specific.
Bottom Line: Memory is pretty cheap these days - more is *much* better!

Alek Komarnitsky                                      303-449-0649
Software Tools Manager, Spatial Technology, Inc.      2425 55th Street, Bldg A
alek@spatial.com                                      Boulder, CO 80301-5704

P.S. I have one HP710 and two X-terms using Interleaf for Desktop Publishing.
     They are pretty heavy users of Interleaf (only), and we see swap usage of
     about 60-70 Mbytes typically. The 710 has 64 Mbytes of RAM, so we're
     almost always in great shape. I'd feel comfortable doubling the Tech Pubs
     staff with the existing server, but not much more. 

     Memory is cheaper than people.  ;-)
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.unix.admin
Subject: Re: Linking /tmp off of root file system
Date: 29 Aug 92 05:02:29 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <BtLvLw.LzH@news.cso.uiuc.edu> walder@alexia.lis.uiuc.edu (John Walder) writes:
|  Our root file system is nearly full. Thus it overflows periodically since
|  vi and mail have /tmp hardcoded in them for creating temporary files.
| 
|  What problems might arise if we did the following?
| 
|    mv tmp tmp.save
|    ln -s /usr/tmp /tmp
| 
|  One problem I foresee is that /usr is not mounted in single user mode.

Just mkdir /usr/tmp before /usr is mounted, while in single user
mode.  You probably want to add something to clean it up on reboot
before /usr is mounted also, so you don't run your root partition
out of space 'invisibly'.

For most current versions of unix, you can also set the TMPDIR
environment variable, and have many programs respect that for
the location of temp files.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.unix.admin
From: fordke@infonode.ingr.com (Keith Ford)
Subject: AnonFTP & automount/NIS/YP
Organization: Intergraph Corporation, Huntsville, AL.
Date: Fri, 4 Sep 1992 18:41:57 GMT


As best I can tell...

I'm have System V 3.1 on a workstation.  It have anonymous ftp
set up and automouter is running under NFS.  Both work as expected
individually, but I cannot find a way to allow an anonymous ftp
user to access an automounted directory.  It appears that the
chroot() that AnonFTP does is confusing the automounter daemon.

I've tried every permutation I can think of, but no luck.  I thought
I could change the temporary mount directory to one within sigth of
the AnonFTP user, then create a /mirror (relative to the chroot)
which was a symbolic link to the temp mount, and use /mount as my
trigger name/thingy.

Any tips would be appreciated.

-- 
Keith E. Ford     __
Intergraph Corp  /  \ Micro Magic BBS 1:373/12  The Dragon Server
+1 205 730-8614  \__/ sysop@umagic.fidonet.org  server@ingr.com
fordke@ingr.com  [__] 830-2362 HST/V32bis 9600  "Subject: HELP"
From: lwall@netlabs.com (Larry Wall)
Newsgroups: comp.unix.admin
Subject: Re: Password Aging
Date: 3 Sep 92 16:37:10 GMT
Organization: NetLabs, Inc.

In article <1992Sep2.124604.6904@mlb.semi.harris.com> dbrillha@dave.mis.semi.harris.com (Dave Brillhart) writes:
: The PERL-based passwd replacement (described in the PERL book and
: available on the net) implements password aging by using a few bits
: in the seed characters that start out the encrypted password. 

Lest this worry someone unnecessarily, I should point out that this
encoding method doesn't negate the effectiveness of the salt characters.
It actually usurps half of the bits to hold the number of weeks since
1970, modulo 64, but it purturbs this number using the first two bytes
of the login id, so even if everyone on the machine changes their
password in the same week, everyone still gets a different salt (unless
you start everyone's login id with the same two characters, of course).

: We use the utility and it works great. Besides password aging, you
: get a terrific pro-active password checker - it will not allow
: "easy" passwords (defined by you using REs and dictionaries). It
: keeps you from having to run crack as often :-)

Thanks for the plug.  I agree that pro-active is much better than
post-active (con-active? amateur-active?).  Programs like crack
don't buy you much unless you enjoy tormenting your CPU.

(Potential pro-active passwd program programmer pedagogoical pointer:
Don't write a program that dictates what kind of passwords are GOOD--in
general this greatly reduces the search space for a cracker who knows
how to generate "good" passwords.  Your program should only worry about
what kinds of passwords are BAD.  If you let your users figure out a
good way to generate passwords, they won't all choose the same way.)

Larry Wall
lwall@netlabs.com
Newsgroups: comp.unix.admin
From: Steinar.Haug@delab.sintef.no (Steinar Haug)
Subject: Re: SECURITY -- How to list files having suid
Organization: SINTEF DELAB, Trondheim, Norway.
	<1992Aug27.181633.6131@odin.corp.sgi.com> <az!1Hrcg89@atlantis.psu.edu>
Distribution: world,local
Date: 27 Aug 92 22:25:45

In article <az!1Hrcg89@atlantis.psu.edu> barr@pop.psu.edu (David Barr) writes:
> (are there find's that don't have the '-ls' option?)

Yes, certainly. HP-UX find still doesn't have it in HP-UX 8.0, for example.

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no
From: mwilson@orl.mmc.com (Mark Wilson)
Newsgroups: comp.unix.admin
Subject: Password Aging
Date: 26 Aug 92 16:31:17 GMT
Reply-To: mwilson@orl.mmc.com
Organization: Martin Marietta Orlando

I have been tasked with finding/ creating a tool to provide password aging
for a heterogenous net. One reference I have says there are such tools.
Unfortunately, they don't name names. I would ask archie, but I don't know
what to ask for. Any help would be greatly appreciated.

Thanks for sharing your knowledge and expertise.

----------------------------------------------------------------------
Mark Wilson                              Martin Marietta E,I & M Group
mwilson@orl.mmc.com                      Mail Point 170
Phone: (407)356-6386                     P.O. Box 555837
Fax:   (407)436-5482                     Orlando, FL, 32855-5837
My opinions are my opinions, Martin Marietta can speak for itself.
From: dtb@otto.bf.rmit.oz.au (David Bath)
Newsgroups: comp.unix.admin
Subject: Re: Linking /tmp off of root file system
Date: 31 Aug 92 01:50:19 GMT
Organization: RMIT Computer Centre, Melbourne Australia.

walder@alexia.lis.uiuc.edu (John Walder) writes:


> Our root file system is nearly full. Thus it overflows periodically since
> vi and mail have /tmp hardcoded in them for creating temporary files.
> What problems might arise if we did the following?
>   mv tmp tmp.save
>   ln -s /usr/tmp /tmp
> One problem I foresee is that /usr is not mounted in single user mode.

The other thing to remember is to look at the TMPDIR variable used by
some of the temporary file creation functions such as mktemp, tempnam
et al.  This is quite handy and can point to another disk WHEN you
are in multiuser mode ---- /etc/profile can check which disks are
mounted and set TMPDIR accordingly.

You could then check whether your vi uses $TMPDIR or get a clone such as
elvis and ensure that it does (ain't source code great!)

Regards

========================================================================
David T. Bath
email: 	dtb@otto.bf.rmit.oz.au
Work: 	Global Technology Corporation, Carlton, Vic, OZ  (03) 3477511
=======================================================================
From: jfh@rpp386.lonestar.org (John F. Haugh II)
Newsgroups: comp.unix.admin
Subject: Re: Password Aging
Date: 27 Aug 92 12:58:22 GMT
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: River Parishes Programming, Austin, Republic of Texas

In article <1992Aug26.163117.28008@iplmail.orl.mmc.com> mwilson@orl.mmc.com writes:
>I have been tasked with finding/ creating a tool to provide password aging
>for a heterogenous net. One reference I have says there are such tools.
>Unfortunately, they don't name names. I would ask archie, but I don't know
>what to ask for. Any help would be greatly appreciated.

You would want the Shadow Password Suite.  It includes two tools for
doing password aging, passwd and chage.  The passwd command under SVR4
includes options for setting various parts of the age information.  It
may be compiled to run on other-than-SVR4 systems.  The chage command
allows you to change any part of the age info you want.  It too runs
on a number of different systems.

It is available from better archive sites everywhere.  The archive
name is "shadow".
-- 
John F. Haugh II                   | "The US Government has the Midas Muffler
Ma Bell: (512) 251-2151            |  touch: everything they touch turns to
UUCP: ...!cs.utexas.edu!rpp386!jfh |  shit."
Domain: jfh@rpp386.cactus.org      |                  -- Jay Maynard
Newsgroups: comp.unix.admin
From: zs@munta.cs.mu.OZ.AU (Zoltan Somogyi)
Subject: Re: Vendors Considered Evil (Re: Perl use over NFS)
Organization: Computer Science, University of Melbourne, Australia
Date: Mon, 31 Aug 1992 09:23:16 GMT

kochmar@sei.cmu.edu (John Kochmar) writes:
>You've gotta be kidding, right?  You're not advocating that perl be
>placed in /usr/bin so that scripts you pick up from who-knows-where
>will run without modification, right?

No, that's not why you want it.

I am regularly using several machines from several vendors. On all these
machines except one, my home directory is NFS mounted, so that I see the
same files when I log in. I have a ~/bin/sgi subdirectory, a ~/bin/sun4 etc,
as well as a ~/bin/scripts. Whatever I put into ~/bin/scripts should work
the same on every machine. This is true for scripts whose interpreters
are in known standard locations, such as /bin/sh and /bin/awk*. It does
not work if different machines put perl in different directories. Instead,
I have to make several copies of the script and put them in ~/bin/<arch>,
with the usual double maintenance problem if I ever need to fix or enhance
the script.

*: actually, for reasons best known to themselved SGI put awk in /usr/local/bin,
causing this very problem.

Zoltan Somogyi <zs@cs.mu.OZ.AU>
Department of Computer Science, University of Melbourne, AUSTRALIA