OpenPKG CVS Repository
http://cvs.openpkg.org/
____________________________________________________________________________
Server: cvs.openpkg.org Name: Thomas Lotterer
Root: /e/openpkg/cvs Email: [EMAIL PROTECTED]
Module: openpkg-doc Date: 02-Apr-2003 15:02:16
Branch: HEAD Handle: 2003040214021500
Modified files:
openpkg-doc/handbook openpkg.xml
Log:
rewrite documentation about "Userids and Groupids"
Summary:
Revision Changes Path
1.69 +61 -25 openpkg-doc/handbook/openpkg.xml
____________________________________________________________________________
patch -p0 <<'@@ .'
Index: openpkg-doc/handbook/openpkg.xml
============================================================================
$ cvs diff -u -r1.68 -r1.69 openpkg.xml
--- openpkg-doc/handbook/openpkg.xml 2 Apr 2003 10:04:29 -0000 1.68
+++ openpkg-doc/handbook/openpkg.xml 2 Apr 2003 13:02:15 -0000 1.69
@@ -716,14 +716,52 @@
<sect1 id='security-usergroup'>
<title>Security Through Userids and Groupids</title>
<para>
- OpenPKG installs three userid and groupid pairs during bootstrap.
- OpenPKG is designed with good security in mind, and thus provides four
- userid and groupid pairs. Whereas one pair might often suffice, the
- four distinct pairs allow for finer granularity. In some cases, a
- software application will actually require a more privileged or less
- privileged user and group pair in addition to the normal pair. Many
- daemon packages use such special users and groups for improving
- security, for example.
+ Many daemon packages use special users and groups for improving
+ security. OpenPKG uses four distinct Unix user/group id pairs.
+ They are specified during the bootstrap process of an instance.
+ The eight names can either be set individually or a common
+ prefix can be specified. Existing system users can be choosen
+ to allow indirect control of user/group numbers and to integrate
+ OpenPKG into enterprise environments with networked (i.e. NIS,
+ LDAP) account management. It's up to the administrator to
+ decide if one or more OpenPKG user/group functionalities use the
+ same account, whether preexisting system accounts are being used
+ or not and if accounts are reused accross OpenPKG instances and
+ even machines. In case of a non-privileged OpenPKG instance, all
+ users and groups usually map to a single pair. Please note that
+ some software packages (i.e. sendmail, postfix) actually
+ require the user/group ids to be different. They verify this at
+ run-time and will refuse to work if the setup violates their
+ hardcoded security policies. The pay off consolidating multiple
+ OpenPKG user/group functionalities into a single Unix account is
+ the inability to continue use of those applications. In fact,
+ enabling those applications were the driving force behind
+ OpenPKG to support multiple users.
+ </para>
+ <para>
+ Please understand that while additional users and groups help to
+ isolate OpenPKG from the host and one OpenPKG instance from
+ another, the gain in security is still small. To protect files
+ from being accidentally overwritten during development of a
+ package, a developer must use the OpenPKG feature of building a
+ package as non-root. Even this is not perfect and sometimes it's
+ best to dedicate a machine to development. Installing and
+ maintaining daemons, set-uid executables etc. still requires the
+ system administrator to work as "root" or at least begin
+ administration as "root" and substitute user identity with the
+ OpenPKG management user using su(1) or a similar mechanism.
+ Trying to use the additional accounts to exclusively subdelegate
+ administration or to protect the host from OpenPKG
+ instance managers is a waste of time as the managers can easily
+ overwrite files (i.e. cron jobs) which are eventually executed
+ by the superuser. To increase protection of the host and between
+ OpenPKG instances, additional precautions must be taken. Using
+ chroot(1M) on Linux or Solaris aka chroot(8) on FreeBSD is a
+ step in the right direction but it is limited to separating
+ access to files, not sockets or any system calls. Today, the
+ fullest segregation can be achieved through deployment of
+ <ulink url='http://www.solucorp.qc.ca/miscprj/s_context.hc'>vserver</ulink>
+ for Linux or jail(8) for FreeBSD.
</para>
<para>
As described in <xref linkend='bstrap-linked'/>, the installing
@@ -732,19 +770,15 @@
indicates the management user and group. If the administrator does not
explicitly specify the additional superuser, restricted and
non-privileged user and group names, they will be determined by using
- the given management user and group names as a template.
+ the given management user and group names as a prefix.
- By default, the restricted user name will match that of the management
- user, adding a '-r' extension. The non-privileged user name will match
- that of the management user, but add a '-n' extension instead. The
- superuser user name is 'root' by default.
+ By default, the restricted user name will match that of the
+ management user, adding a '-r' extension. The non-privileged
+ user name will match that of the management user, but add a '-n'
+ extension instead. The superuser user name is 'root' by default.
+ The OpenPKG groupids are handled in the same way.
- The new OpenPKG groupids are handled in the same way. For example, if
- an OpenPKG instance is bootstrapped to the directory called 'cw', then
- the four associated userids will be 'cw', 'cw-r', 'cw-n', and 'root'.
- The four associated groupids will be 'cw', 'cw-r', 'cw-n', and 'root'
- or 'wheel' (or whatever the system-particular superuser group name
- is). The administrator can read the unix password file
+ The administrator can read the unix password file
<filename>/etc/passwd</filename> and unix group file
<filename>/etc/group</filename> to see the new entries.
</para>
@@ -752,7 +786,7 @@
<title>Arguments given during bootstrap</title>
<para>
The additional user and group names may be customized to suit the
- needs of the administrator. Additional arguments may be give when
+ needs of the administrator. Additional arguments may be given when
running the bootstrapper (see <xref linkend='bstrap-overview'/>) to
accommodate special user and group names. Specify the name of the
management user with --musr=<name>, the restricted user with
@@ -808,11 +842,13 @@
<title>Using the Userid and Groupid Variables</title>
<!-- FIXME: Give a small user summary, expand, and move following to developer
section -->
<para>
- These user and group names can be queried from within the OpenPKG
- specification file. The variables %{l_musr}, %{l_rusr}, and %{l_nusr}
- expand to the management, restricted, and non-privileged users. The
- variables %{l_mgrp}, %{l_rgrp}, and %{l_ngrp} expand to the
- management, restricted, and non-privileged groups.
+ These user and group names can be queried from within the
+ OpenPKG specification file. The variables %{l_musr}, %{l_rusr},
+ %{l_nusr} and %{l_susr}
+ expand to the management, restricted, non-privileged and
+ superuser. The variables %{l_mgrp}, %{l_rgrp}, %{l_ngrp} and
+ %{l_susr} expand to the management, restricted, and
+ non-privileged groups.
</para>
</sect2>
</sect1>
@@ .
______________________________________________________________________
The OpenPKG Project www.openpkg.org
CVS Repository Commit List [EMAIL PROTECTED]
