diff options
| -rw-r--r-- | configure.ac | 8 | ||||
| -rw-r--r-- | doc/manual/bugs.xml | 28 | ||||
| -rw-r--r-- | doc/manual/introduction.xml | 77 | ||||
| -rw-r--r-- | src/Makefile.am | 2 | ||||
| -rw-r--r-- | src/libmain/shared.cc | 8 |
5 files changed, 88 insertions, 35 deletions
diff --git a/configure.ac b/configure.ac index 2ba8e92384a9..6b041c165c42 100644 --- a/configure.ac +++ b/configure.ac @@ -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], diff --git a/doc/manual/bugs.xml b/doc/manual/bugs.xml index eb479945aba5..4d5017e4402f 100644 --- a/doc/manual/bugs.xml +++ b/doc/manual/bugs.xml @@ -1,7 +1,6 @@ -<appendix> - <title>Bugs / To-Do</title> +<appendix><title>Bugs / To-Do</title> - <itemizedlist> +<itemizedlist> <listitem> <para> @@ -99,17 +98,18 @@ $ 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> +</itemizedlist> </appendix> diff --git a/doc/manual/introduction.xml b/doc/manual/introduction.xml index 02a4383361ca..51804eb9b6fd 100644 --- a/doc/manual/introduction.xml +++ b/doc/manual/introduction.xml @@ -1,17 +1,70 @@ -<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 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>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> + +<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 diff --git a/src/Makefile.am b/src/Makefile.am index 5637382172a2..b7eb905f9273 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -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 diff --git a/src/libmain/shared.cc b/src/libmain/shared.cc index a5c45d853b5c..d0ea3aab8628 100644 --- a/src/libmain/shared.cc +++ b/src/libmain/shared.cc @@ -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. */ |