* Use setre[ug]id() instead of setres[ug]id(), since the former is

more common than the latter (which exists only on Linux and
  FreeBSD).  We don't really care about dropping the saved IDs since
  there apparently is no way to quiry them in any case, so it can't
  influence the build (unlike the effective IDs which are checked by
  Perl for instance).
This commit is contained in:
Eelco Dolstra 2004-09-09 15:55:31 +00:00
parent e043fc7d0b
commit 5396304c73
5 changed files with 88 additions and 35 deletions

View file

@ -151,10 +151,10 @@ if test "$setuid_hack" = "yes"; then
AC_DEFINE(SETUID_HACK, 1, [whether to install Nix setuid])
fi
AC_CHECK_FUNC(setresuid, [HAVE_SETRESUID=1], [HAVE_SETRESUID=])
AM_CONDITIONAL(HAVE_SETRESUID, test "$HAVE_SETRESUID" = "1")
if test "$HAVE_SETRESUID" = "1"; then
AC_DEFINE(HAVE_SETRESUID, 1, [whether we have setresuid()])
AC_CHECK_FUNC(setreuid, [HAVE_SETREUID=1], [HAVE_SETREUID=])
AM_CONDITIONAL(HAVE_SETREUID, test "$HAVE_SETREUID" = "1")
if test "$HAVE_SETREUID" = "1"; then
AC_DEFINE(HAVE_SETREUID, 1, [whether we have setreuid()])
fi
AC_ARG_WITH(nix-user, AC_HELP_STRING([--with-nix-user=USER],

View file

@ -1,5 +1,4 @@
<appendix>
<title>Bugs / To-Do</title>
<appendix><title>Bugs / To-Do</title>
<itemizedlist>
@ -99,16 +98,17 @@ $ nix-store -r $(cat /nix/var/nix/roots/bla)</screen>
</para>
</listitem>
<listitem>
<para>
For security, <command>nix-push</command> manifests should be
digitally signed, and <command>nix-pull</command> should
verify the signatures. The actual NAR archives in the cache
do not need to be signed, since the manifest contains
cryptographic hashes of these files (and
<filename>fetchurl.nix</filename> checks them).
</para>
</listitem>
<listitem><para>For security, <command>nix-push</command> manifests
should be digitally signed, and <command>nix-pull</command> should
verify the signatures. The actual NAR archives in the cache do not
need to be signed, since the manifest contains cryptographic hashes of
these files (and <filename>fetchurl.nix</filename> checks
them).</para></listitem>
<listitem><para>We should switch away from MD5, since it has been
cracked. We don't currently depend very much on the
collision-resistance of MD5, but we will once we start sharing build
results between users.</para></listitem>
</itemizedlist>

View file

@ -1,18 +1,71 @@
<chapter>
<title>Introduction</title>
<chapter><title>Introduction</title>
<epigraph>
<para><quote>The number of Nix installations in the world has grown to 5,
with more expected.</quote></para>
</epigraph>
<epigraph><para><quote>The number of Nix installations in the world
has grown to 5, with more expected.</quote></para></epigraph>
<para>Nix is a system for the deployment of software. Software
deployment is concerned with the creation, distribution, and
management of software components (<quote>packages</quote>). There
are many tools for this, but they tend to ignore some important
requirements for deployment:
<itemizedlist>
<listitem><para><emphasis>Correctness</emphasis>. The basic goal of
software deployment is to transfer software from one machine (e.g.,
the developer's, where it presumably works) to another machine (e.g.,
the end user's). The software should work exactly the same on the
target machine as on the source machine. But this in practice turns
out to be rather difficult due to <emphasis>dependencies between
components</emphasis> and <emphasis>interference between
components</emphasis>. If we deploy a component that depends on other
components, then we should deploy those dependencies as well. If they
are missing on the target system, the component probably won't work.
If they <emphasis>are</emphasis> present but are not the right
version, the component might not work. And if even if they are the
right version, they may have been built with different flags or
options, which can cause incompatibilities. Interference occurs when
components <quote>collide</quote> with each other in the file system.
For instance, different versions of the same package tend to overwrite
each other, so they cannot be installed at the same time. But always
picking the latest version might break components that only work with
some older version.</para></listitem>
<listitem><para><emphasis>Variability</emphasis>. Many package
management tools have difficulty supporting the installation of
multiple versions or variants of the same component. This is bad
because as ...</para></listitem>
</itemizedlist>
<para>
Nix is a system for software deployment. It supports the
creation and distribution of software packages, as well as the installation
and subsequent management of these on target machines (i.e., it is also a
package manager).
</para>
<para>Here are some of Nix's main features:
<itemizedlist>
<listitem><para>Nix can quite reliably figure out the dependencies
between components.</para></listitem>
</itemizedlist>
</para>
<warning><para>This manual is a work in progress. It's quite likely
to be incomplete, inconsistent with the current implementation, or
simply wrong.</para></warning>
<note><para>Some background information on Nix can be found in two
papers. The ICSE 2004 paper <ulink
url='http://www.cs.uu.nl/~eelco/pubs/immdsd-icse2004-final.pdf'><citetitle>Imposing
a Memory Management Discipline on Software
Deployment</citetitle></ulink> discusses the hashing mechanism used to
ensure reliable dependency identification and non-interference between
different versions and variants of packages. The LISA 2004 paper
<citetitle>Nix: A Safe and Policy-Free System for Software
Deployment</citetitle> gives a more general discussion of Nix from a
system-administration perspective.</para></note>
<para>
Nix solves some large problems that exist in most current deployment and
package management systems. <emphasis>Dependency determination</emphasis>

View file

@ -4,7 +4,7 @@ SUBDIRS = bin2c boost libutil libstore libmain nix-store nix-hash \
SETUID_PROGS = nix-store nix-instantiate nix-env
install-exec-hook:
if SETUID_HACK
if HAVE_SETRESUID
if HAVE_SETREUID
cd $(DESTDIR)$(bindir) && chown @NIX_USER@ $(SETUID_PROGS) \
&& chgrp @NIX_GROUP@ $(SETUID_PROGS) && chmod ug+s $(SETUID_PROGS)
else

View file

@ -169,9 +169,9 @@ static void initAndRun(int argc, char * * argv)
}
#if HAVE_SETRESUID
#define _setuid(uid) setresuid(uid, uid, uid)
#define _setgid(gid) setresgid(gid, gid, gid)
#if HAVE_SETREUID
#define _setuid(uid) setreuid(uid, uid)
#define _setgid(gid) setregid(gid, gid)
#else
/* Only works properly when run by root. */
#define _setuid(uid) setuid(uid)
@ -208,7 +208,7 @@ void switchToNixUser()
/* !!! Apparently it is unspecified whether getgroups() includes
the effective gid. In that case the following test is always
true *if* the program is installed setgid (which we do when we
have setresuid()). On Linux this doesn't appear to be the
have setreuid()). On Linux this doesn't appear to be the
case, but we should switch to the real gid before doing this
test, and then switch back to the saved gid. */