* 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
parent
e043fc7d0b
commit
5396304c73
|
|
@ -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],
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
</itemizedlist>
|
||||
<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>
|
||||
|
||||
</appendix>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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. */
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue