Very Computer

Anyone knows (short of using adb on the kernel) where to see the defaults
used in the /etc/system file? And what are the available tuning
parameters? sysdef lists some, but there seems to be more...

For example, it says in the man page of system(4) that maxusers is
"a useful tuning parameter"... But what is the default value (seems
to be 8, from using adb)? Nowhere in TFM does it seem to have a
complete list of those "useful tuning parameters".

Anyone in on the "secrets" care to comment? Thanks for any info.

--

                                        Christian Iseli
                                        LSL-DI-EPFL
                                        Lausanne, Switzerland

The default value isn't 8.  The default value is scaled
with the amount of memory.  The maxusers parameter scales
a number of other parameters, all of which can be set individually.

One of the most commonly asked parameters:

        set pt_cnt = <n>  * number of SysV ptys

Personnaly recommended:

        set nfs:nfs_portmon  = 1 * for increased fileserver security.

Casper

it appears the default GENERIC value is 8, pg 116 SunOS 5.2 Administering
Security, Performance, and Accounting.

Quote:>with the amount of memory.  The maxusers parameter scales
>a number of other parameters, all of which can be set individually.

the parameters ncallout, ufs_ninode, ncsize, max_nprocs, ndquot, and maxuprc
are affected by maxusers, reference pg 116 and Table 6-1 pg 117.

Quote:>One of the most commonly asked parameters:

>    set pt_cnt = <n>  * number of SysV ptys

the following is a bit of pseudo tty wisdom from bill wisner. none of
this stuff is covered in the manuals/answerbook, go figure. there is
supposed to be man page for pty(4) as given by man xterm(1) but it
is vapor.

"ntpy controls the number of BSD-style compatibility pty devices.  These
are only present for compatibility and none of the programs that are part
of the Solaris system as shipped use them.  You cannot go above 48 of
these devices in the stock 2.2 release; Sun has issued a patch that corrects
this problem and allows you to configure as many as you want.  However,
you must use mknod to manually create the device nodes.

pt_cnt controls the number of pts devices.  These are System V pseudo-ttys.
in.telnetd and in.rlogind use these.  Any software which was properly written
to work on System V uses these.  If you change this number and do a boot -r,
the kernel will build the correct number of device nodes in /dev/pts.
(Note, though, that it will not remove old ones, so if you *lower* pt_cnt
you will have to manually remove the extra device nodes.)"

Quote:>Personnaly recommended:

>    set nfs:nfs_portmon  = 1 * for increased fileserver security.

the complete list of tunable kernel parameters is obtained by using
/usr/ccs/bin/nm /kernel/unix. /usr/sbin/sysdef -i shows current values
assigned to kernel parameters. reference Appendix A pg 197.

regards,

Casper Dik says (of maxusers):

Quote:>>The default value isn't 8.  The default value is scaled
>>with the amount of memory.  The maxusers parameter scales
>>a number of other parameters, all of which can be set individually.

James A. Peters says:

Quote:>it appears the default GENERIC value is 8, pg 116 SunOS 5.2 Administering
>Security, Performance, and Accounting.

My kernel says:

# adb -k /kernel/unix /dev/mem
physmem 7d9e
maxusers?
maxusers:
maxusers:       20              = unimp         0x1e

20 hexadecimal is 32 decimal which is apparently the default value
for maxusers in Solaris 2.2.  So who's right?

Quote:>there is supposed to be man page for pty(4) as given by man xterm(1) but it
>is vapor.

As far as I can determine the BSD-style pty devices in Solaris 2.2 are
documented nowhere.  If you really want to know, go packing back to
your SunOS 4.1 manuals.  It really is a good idea to make your software
use the pts devices instead of ptys, though - the pts drivers are a
standard part of SVR4 while the BSD prt driver was apparently grafted
on by Sun as a compatibility afterthought.  The pts drivers are probably
much better supported.

Quote:>the complete list of tunable kernel parameters is obtained by using
>/usr/ccs/bin/nm /kernel/unix. /usr/sbin/sysdef -i shows current values
>assigned to kernel parameters. reference Appendix A pg 197.

sysdef -i only shows a handful of the tunable parameters -- those few
that Sun officially condones the use of.  I find it quite amusing that
the manual instructs users to use nm to get a list of tunable parameters
from the kernel, as nm will list every kernel symbol that can possibly
be set, most with unpredictable and possibly quite disastrous results.
That bit was a real gaffe on the part of Sun's technical writers.
--

Quote:>>The default value isn't 8.  The default value is scaled

>it appears the default GENERIC value is 8, pg 116 SunOS 5.2 Administering
>Security, Performance, and Accounting.

>>with the amount of memory.  The maxusers parameter scales
>>a number of other parameters, all of which can be set individually.

In Solaris 2.3 the value of maxusers does scale with the amount of
memory and the parameters listed below scale with maxusers.  If
the 2.3 manual says otherwise it is wrong.

maxusers ~= #megabytes physical memory
(minimum 8, maximum default 1024, maximum setable 2048)

        -David

I am.  It says so in the source.  First, I believe what I observe,
then I believe the source and the least reliable
source of information is the documentation.

Quote:}As far as I can determine the BSD-style pty devices in Solaris 2.2 are
}documented nowhere.  If you really want to know, go packing back to
}your SunOS 4.1 manuals.  It really is a good idea to make your software
}use the pts devices instead of ptys, though - the pts drivers are a
}standard part of SVR4 while the BSD prt driver was apparently grafted
}on by Sun as a compatibility afterthought.  The pts drivers are probably
}much better supported.

And they're much easier to use.  Nor do you need to hardcode
the number of ptys you expect on a system, nor do you need to
be root, nor are there any problems with race conditions during
allocations.

BSD ptys are a hack.  I don't miss them.

Quote:}sysdef -i only shows a handful of the tunable parameters -- those few
}that Sun officially condones the use of.  I find it quite amusing that
}the manual instructs users to use nm to get a list of tunable parameters
}from the kernel, as nm will list every kernel symbol that can possibly
}be set, most with unpredictable and possibly quite disastrous results.
}That bit was a real gaffe on the part of Sun's technical writers.

It also lists all the functions and what not in the kernel.
nm prints the names of the symbols, as they appear in /dev/ksyms.

Variables such as nfs:nfs_portmon show up as nfs_portmon, but
you can't set nfs_portmon.  Often you need to specify the
module name first.

Casper

Quote:>Personnaly recommended:
>    set nfs:nfs_portmon  = 1 * for increased fileserver security.

What does this do?

--

  PGP2.3 public key available via keyserver, finger, or email.
  Member of the League for Programming Freedom and the ACLU.

Checks that all NFS requests come from a port # < 1024.

What does this buy you?  Simple, w/ nfs_portmon set to 0, any
user can implement and run their own nfs client code on their
workstation.  This allows them access to all files that can possibly
accessed from this workstation. (I.e, effectively ``su user'' for
any user id when it comes to NFS file access)

Most crackers nowadays have ready-to-run copies of such NFS
user-mode clients.

In SunOS 4.x, the variable nfs_portmon controls the same.
(In rc.local this variable is set to 1 if /etc/security/passwd.adjunct
exists, you can turn it on by default.)

Casper

Quote:>>>    set nfs:nfs_portmon  = 1 * for increased fileserver security.
>Checks that all NFS requests come from a port # < 1024.
>What does this buy you?  Simple, w/ nfs_portmon set to 0, any
>user can implement and run their own nfs client code on their
>workstation.  This allows them access to all files that can possibly
>accessed from this workstation. (I.e, effectively ``su user'' for
>any user id when it comes to NFS file access)

This would require the user to first guess a filehandle, would it not?
--

In SunOS 4.x, nfs_portmon and rpc.mountd are usually started equally
insecure (rpc.mountd -n is teh default when not using shadow password).
In Solaris 2.x, you'll need to guess a file handle.  I wonder how
difficult that really is.  A lot of file handle information
is leaked to user land through log messages.

Casper