Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Claes Wallin (韋嘉誠)]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

On 16-Aug-2015 2:19 pm, "David Thompson" <davet@gnu.org> wrote:

Great! I ran into this when trying to compile and run guix on a machine at
work, where I'm not root.

I was planning to run guix as a stow of steroids. But I'm still wondering
whether what I'm attempting is even intended to be possible? Of course, I
would lose the benefits of user separation, chroot, hydra (because I can't
write to /gnu) etc, but is guix even made to be able to downgrade to this
situation?

[-- Attachment #2: Type: text/html, Size: 594 bytes --]

Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Claes Wallin (韋嘉誠)]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

[Reposting with correct sender. Sorry, David.]

Great! I ran into this when trying to compile and run guix on a machine at
work, where I'm not root.

I was planning to run guix as a stow of steroids. But I'm still wondering
whether what I'm attempting is even intended to be possible? Of course, I
would lose the benefits of user separation, chroot, hydra (because I can't
write to /gnu) etc, but is guix even made to be able to downgrade to this
situation?

[-- Attachment #2: Type: text/html, Size: 526 bytes --]

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Eric Bavier]

On Mon, 17 Aug 2015 14:45:28 +0200
Claes Wallin (韋嘉誠) <gnu@clacke.user.lysator.liu.se> wrote:

> On Sun, Aug 16, 2015 at 4:01 PM, Claes Wallin (韋嘉誠)
> <gnu@clacke.user.lysator.liu.se> wrote:
> > [Reposting with correct sender. Sorry, David.]
> >
> > Great! I ran into this when trying to compile and run guix on a
> > machine at work, where I'm not root.
> >
> > I was planning to run guix as a stow of steroids. But I'm still
> > wondering whether what I'm attempting is even intended to be
> > possible? Of course, I would lose the benefits of user separation,
> > chroot, hydra (because I can't write to /gnu) etc, but is guix even
> > made to be able to downgrade to this situation?
> 
> Answering myself: It is there in the Fine Manual. So it's intended to
> work. I will try this and see how far I come.
> 
> https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup
> 
> "If you are installing Guix as an unprivileged user, it is still
> possible to run guix-daemon provided you pass --disable-chroot."
> 

I have experimented with this a bit lately.  It works to some extent,
but I have had to apply a few patches to some package recipes.  Some
packages have failing tests (where presumably they would pass or be
skipped in the chroot), which I have disabled for the time being just
to move along.

I can post a few of the patches to the ML later.

`~Eric

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Claes Wallin (韋嘉誠)]

On Sun, Aug 16, 2015 at 4:01 PM, Claes Wallin (韋嘉誠)
<gnu@clacke.user.lysator.liu.se> wrote:
> [Reposting with correct sender. Sorry, David.]
>
> Great! I ran into this when trying to compile and run guix on a machine at
> work, where I'm not root.
>
> I was planning to run guix as a stow of steroids. But I'm still wondering
> whether what I'm attempting is even intended to be possible? Of course, I
> would lose the benefits of user separation, chroot, hydra (because I can't
> write to /gnu) etc, but is guix even made to be able to downgrade to this
> situation?

Answering myself: It is there in the Fine Manual. So it's intended to
work. I will try this and see how far I come.

https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup

"If you are installing Guix as an unprivileged user, it is still
possible to run guix-daemon provided you pass --disable-chroot."

-- 
   /c

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Claes Wallin (韋嘉誠)]

On Mon, Aug 17, 2015 at 10:33 AM, Eric Bavier
<ericbavier@openmailbox.org> wrote:
> On Mon, 17 Aug 2015 14:45:28 +0200
> Claes Wallin (韋嘉誠) <gnu@clacke.user.lysator.liu.se> wrote:
>> On Sun, Aug 16, 2015 at 4:01 PM, Claes Wallin (韋嘉誠)
>> <gnu@clacke.user.lysator.liu.se> wrote:
>> > [Reposting with correct sender. Sorry, David.]
>> >
>> > Great! I ran into this when trying to compile and run guix on a
>> > machine at work, where I'm not root.
>> >
>> > I was planning to run guix as a stow of steroids. But I'm still
>> > wondering whether what I'm attempting is even intended to be
>> > possible? Of course, I would lose the benefits of user separation,
>> > chroot, hydra (because I can't write to /gnu) etc, but is guix even
>> > made to be able to downgrade to this situation?
>>
>> Answering myself: It is there in the Fine Manual. So it's intended to
>> work. I will try this and see how far I come.
>>
>> https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup
>>
>> "If you are installing Guix as an unprivileged user, it is still
>> possible to run guix-daemon provided you pass --disable-chroot."
>>
>
> I have experimented with this a bit lately.  It works to some extent,
> but I have had to apply a few patches to some package recipes.  Some
> packages have failing tests (where presumably they would pass or be
> skipped in the chroot), which I have disabled for the time being just
> to move along.
>
> I can post a few of the patches to the ML later.

I'm doing this from git now, as opposed to doing it from the tarball
earlier, because I want that setns patch.

I have compiled gettext, m4, autoconf, automake and guile and its
deps, installed in /home/myuser/.local.

Rather than run ./bootstrap, I've had to run gettextize, aclocal,
autoreconf -vi (no -f!) with CPATH, LIBRARY_PATH and maybe AC_MACRODIR
(probably not necessary), and I managed to get a ./configure, but it
now tells me:

./configure: line 6782: syntax error near unexpected token `GUILE,'
./configure: line 6782: `PKG_CHECK_MODULES(GUILE, guile-2.0 >= 2.0.7)'

guile.m4 is there in my .../aclocal/guile.m4. I had to run aclocal
manually, because otherwise it would say something about
PKG_CHECK_MODULES being undefined.


Seems like this little endeavor is hitting a lot of special cases.

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Claes Wallin (韋嘉誠)]

On Mon, Aug 17, 2015 at 3:42 PM, Claes Wallin (韋嘉誠)
<gnu@clacke.user.lysator.liu.se> wrote:
> On Mon, Aug 17, 2015 at 10:33 AM, Eric Bavier
> <ericbavier@openmailbox.org> wrote:

>>> https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup
>>>
>>> "If you are installing Guix as an unprivileged user, it is still
>>> possible to run guix-daemon provided you pass --disable-chroot."
>>>
>>
>> I have experimented with this a bit lately.  It works to some extent,
>> but I have had to apply a few patches to some package recipes.  Some
>> packages have failing tests (where presumably they would pass or be
>> skipped in the chroot), which I have disabled for the time being just
>> to move along.
>>
>> I can post a few of the patches to the ML later.
>
> I'm doing this from git now, as opposed to doing it from the tarball
> earlier, because I want that setns patch.
>
> I have compiled gettext, m4, autoconf, automake and guile and its
> deps, installed in /home/myuser/.local.

And now I added sqlite and pkg-config as well, because looking at the
diff between tarball configure and my configure told me those were
missing. This helped me forward!


> Rather than run ./bootstrap, I've had to run gettextize, aclocal,
> autoreconf -vi (no -f!) with CPATH, LIBRARY_PATH and maybe AC_MACRODIR
> (probably not necessary), and I managed to get a ./configure, but it
> now tells me:


Now I'm doing this:

git clean -fxd && # recover from previous attempts
git checkout HEAD . && # ditto
gettextize --po-dir=po{/guix,/packages,} &&
sed -re '/^[[:blank:]]*po\/(guix|packages)\/Makefile.in[[:blank:]]*$/d'
-i configure.ac && # because gettextize creates redundant entries for
these, over which alocal gets very upset
aclocal -I m4 &&
AUTOPOINT=true autoreconf -vi


And after a "LIBRARY_PATH=/home/myuser/.local/lib
CPATH=/home/myuser/.local/include ./configure
--prefix=/home/eclewal/.local" it looks like I'm able to compile!

Thanks for putting up with my rubber-ducking.

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Claes Wallin (韋嘉誠)]

On Mon, Aug 17, 2015 at 4:27 PM, Claes Wallin (韋嘉誠)
<gnu@clacke.user.lysator.liu.se> wrote:

> Now I'm doing this:
>
> git clean -fxd && # recover from previous attempts
> git checkout HEAD . && # ditto
> gettextize --po-dir=po{/guix,/packages,} &&
> sed -re '/^[[:blank:]]*po\/(guix|packages)\/Makefile.in[[:blank:]]*$/d'
> -i configure.ac && # because gettextize creates redundant entries for
> these, over which alocal gets very upset
> aclocal -I m4 &&
> AUTOPOINT=true autoreconf -vi
>
>
> And after a "LIBRARY_PATH=/home/myuser/.local/lib
> CPATH=/home/myuser/.local/include ./configure
> --prefix=/home/myuser/.local" it looks like I'm able to compile!

ice-9/boot-9.scm:106:20: In procedure #<procedure b1f9c0 at
ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not found: setns
make[2]: *** [guix/git-download.go] Error 1

Right, not merged yet! I'll patch it locally ... So I might as well
have done this on the tarball. Well well, I learned some autotools
acrobatics on the way.

> Thanks for putting up with my rubber-ducking.

Doubly so.

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Thompson, David]

On Mon, Aug 17, 2015 at 4:33 AM, Eric Bavier <ericbavier@openmailbox.org> wrote:
> On Mon, 17 Aug 2015 14:45:28 +0200
> Claes Wallin (韋嘉誠) <gnu@clacke.user.lysator.liu.se> wrote:
>
>> On Sun, Aug 16, 2015 at 4:01 PM, Claes Wallin (韋嘉誠)
>> <gnu@clacke.user.lysator.liu.se> wrote:
>> > [Reposting with correct sender. Sorry, David.]
>> >
>> > Great! I ran into this when trying to compile and run guix on a
>> > machine at work, where I'm not root.
>> >
>> > I was planning to run guix as a stow of steroids. But I'm still
>> > wondering whether what I'm attempting is even intended to be
>> > possible? Of course, I would lose the benefits of user separation,
>> > chroot, hydra (because I can't write to /gnu) etc, but is guix even
>> > made to be able to downgrade to this situation?
>>
>> Answering myself: It is there in the Fine Manual. So it's intended to
>> work. I will try this and see how far I come.
>>
>> https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup
>>
>> "If you are installing Guix as an unprivileged user, it is still
>> possible to run guix-daemon provided you pass --disable-chroot."
>>
>
> I have experimented with this a bit lately.  It works to some extent,
> but I have had to apply a few patches to some package recipes.  Some
> packages have failing tests (where presumably they would pass or be
> skipped in the chroot), which I have disabled for the time being just
> to move along.

I think that to really make unprivileged use of Guix work acceptably,
we need to use the user namespaces feature first introduced in Linux
3.8.  This would allow unprivileged users to build software in the
same type of isolated environments that are used when running the
daemon as root.

- Dave

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Claes Wallin (韋嘉誠)]

On Mon, Aug 17, 2015 at 4:34 PM, Thompson, David
<dthompson2@worcester.edu> wrote:
> On Mon, Aug 17, 2015 at 4:33 AM, Eric Bavier <ericbavier@openmailbox.org> wrote:
>> On Mon, 17 Aug 2015 14:45:28 +0200
>> Claes Wallin (韋嘉誠) <gnu@clacke.user.lysator.liu.se> wrote:

>>> https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup
>>>
>>> "If you are installing Guix as an unprivileged user, it is still
>>> possible to run guix-daemon provided you pass --disable-chroot."
>>>
>>
>> I have experimented with this a bit lately.  It works to some extent,
>> but I have had to apply a few patches to some package recipes.  Some
>> packages have failing tests (where presumably they would pass or be
>> skipped in the chroot), which I have disabled for the time being just
>> to move along.
>
> I think that to really make unprivileged use of Guix work acceptably,
> we need to use the user namespaces feature first introduced in Linux
> 3.8.  This would allow unprivileged users to build software in the
> same type of isolated environments that are used when running the
> daemon as root.


Working at all is acceptable to me.

Do namespaces really work for non-root? That's more awesome than I
expected. But without being able to point out how, it sounds to me
like it could easily be a privilege escalation waiting to happen,
unless you do it as compartmentalized as the Hurd does it ... which
Linux won't.

-- 
   /c

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Claes Wallin (韋嘉誠)]

I'm almost done talking to myself, I promise. This is just all very exciting.

On Mon, Aug 17, 2015 at 4:31 PM, Claes Wallin (韋嘉誠)
<gnu@clacke.user.lysator.liu.se> wrote:
> On Mon, Aug 17, 2015 at 4:27 PM, Claes Wallin (韋嘉誠)
> <gnu@clacke.user.lysator.liu.se> wrote:
>
>> Now I'm doing this:
>>
>> git clean -fxd && # recover from previous attempts
>> git checkout HEAD . && # ditto
>> gettextize --po-dir=po{/guix,/packages,} &&
>> sed -re '/^[[:blank:]]*po\/(guix|packages)\/Makefile.in[[:blank:]]*$/d'
>> -i configure.ac && # because gettextize creates redundant entries for
>> these, over which alocal gets very upset
>> aclocal -I m4 &&
>> AUTOPOINT=true autoreconf -vi
>>
>>
>> And after a "LIBRARY_PATH=/home/myuser/.local/lib
>> CPATH=/home/myuser/.local/include ./configure
>> --prefix=/home/myuser/.local" it looks like I'm able to compile!

--prefix=/home/myuser/.local/opt/guix

I don't want stow and guix to control the same namespace.


> ice-9/boot-9.scm:106:20: In procedure #<procedure b1f9c0 at
> ice-9/boot-9.scm:97:6 (thrown-k . args)>:
> ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not found: setns
> make[2]: *** [guix/git-download.go] Error 1
>
> Right, not merged yet! I'll patch it locally ... So I might as well
> have done this on the tarball. Well well, I learned some autotools
> acrobatics on the way.

Patching worked, and ./pre-inst-env guix build bootstrap is now done
doing its massive downloads, made some kind of xz, bash and gcc etc,
and has started compiling glibc. Sweet. Maybe this is it. Fingers
crossed.

>> Thanks for putting up with my rubber-ducking.
>
> Doubly so.

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Thompson, David]

On Mon, Aug 17, 2015 at 11:16 AM, Claes Wallin (韋嘉誠)
<gnu@clacke.user.lysator.liu.se> wrote:
> On Mon, Aug 17, 2015 at 4:34 PM, Thompson, David
> <dthompson2@worcester.edu> wrote:
>> On Mon, Aug 17, 2015 at 4:33 AM, Eric Bavier <ericbavier@openmailbox.org> wrote:
>>> On Mon, 17 Aug 2015 14:45:28 +0200
>>> Claes Wallin (韋嘉誠) <gnu@clacke.user.lysator.liu.se> wrote:
>
>>>> https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup
>>>>
>>>> "If you are installing Guix as an unprivileged user, it is still
>>>> possible to run guix-daemon provided you pass --disable-chroot."
>>>>
>>>
>>> I have experimented with this a bit lately.  It works to some extent,
>>> but I have had to apply a few patches to some package recipes.  Some
>>> packages have failing tests (where presumably they would pass or be
>>> skipped in the chroot), which I have disabled for the time being just
>>> to move along.
>>
>> I think that to really make unprivileged use of Guix work acceptably,
>> we need to use the user namespaces feature first introduced in Linux
>> 3.8.  This would allow unprivileged users to build software in the
>> same type of isolated environments that are used when running the
>> daemon as root.
>
>
> Working at all is acceptable to me.
>
> Do namespaces really work for non-root? That's more awesome than I
> expected. But without being able to point out how, it sounds to me
> like it could easily be a privilege escalation waiting to happen,
> unless you do it as compartmentalized as the Hurd does it ... which
> Linux won't.

Yes, user namespaces can be created by unprivileged users. The user
that created the namespace then has root in the context of the new
namespace, which allows for creating all of the other types of
namespaces.  There's been some bumps along the way, such as a security
bug with groups that prompted the addition of the
/proc/<pid>/setgroups file in Linux 3.19 (I think) that has since been
backported to earlier kernel releases, the oldest I know of being
3.13.  But overall, this feature is very good and using it for Guix
would allow for the unprivileged daemon to take advantage of almost
all of the isolation techniques used by the privileged daemon.

- Dave

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Claes Wallin (韋嘉誠)]

On Mon, Aug 17, 2015 at 5:25 PM, Thompson, David
<dthompson2@worcester.edu> wrote:
> On Mon, Aug 17, 2015 at 11:16 AM, Claes Wallin (韋嘉誠)
> <gnu@clacke.user.lysator.liu.se> wrote:

>>> I think that to really make unprivileged use of Guix work acceptably,
>>> we need to use the user namespaces feature first introduced in Linux
>>> 3.8.  This would allow unprivileged users to build software in the
>>> same type of isolated environments that are used when running the
>>> daemon as root.
>>
>>
>> Working at all is acceptable to me.
>>
>> Do namespaces really work for non-root? That's more awesome than I
>> expected. But without being able to point out how, it sounds to me
>> like it could easily be a privilege escalation waiting to happen,
>> unless you do it as compartmentalized as the Hurd does it ... which
>> Linux won't.
>
> Yes, user namespaces can be created by unprivileged users. The user
> that created the namespace then has root in the context of the new
> namespace, which allows for creating all of the other types of
> namespaces.  There's been some bumps along the way, such as a security
> bug with groups that prompted the addition of the
> /proc/<pid>/setgroups file in Linux 3.19 (I think) that has since been
> backported to earlier kernel releases, the oldest I know of being
> 3.13.  But overall, this feature is very good and using it for Guix
> would allow for the unprivileged daemon to take advantage of almost
> all of the isolation techniques used by the privileged daemon.

That is really awesome for all kinds of things. Wow.

On this system though, setns doesn't exist, so I'm happy to get even a
stow on steroids working, which actually seems to be the case at this
point. Thank you all guix for making this awesome system!

-- 
   /c

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Claes Wallin (韋嘉誠)]

On Mon, Aug 17, 2015 at 10:33 AM, Eric Bavier
<ericbavier@openmailbox.org> wrote:

> I have experimented with this a bit lately.  It works to some extent,
> but I have had to apply a few patches to some package recipes.  Some
> packages have failing tests (where presumably they would pass or be
> skipped in the chroot), which I have disabled for the time being just
> to move along.
>
> I can post a few of the patches to the ML later.


Any patches related to bootstrapping gcc? I'm getting lib/lib64 confusion.

/home/myuser/.local/opt/guix/guix/store/i901f9ad7j3cq7liaiszgpkcjs9mnw5p-libstdc++-4.9.3/lib64
*does* have a libstdc++.a.

I'm doing the ugly thing for now. Just removing the empty lib and
making it a symlink from lib64.


g++   -g -DIN_GCC    -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE
-Wl,-rpath=/home/myuser/.local/opt/guix/guix/store/llnj407l7gh3mz4jjsj6ymc6ph2a7hg6-glibc-2.21/lib
-Wl,-dynamic-linker
-Wl,/home/myuser/.local/opt/guix/guix/store/llnj407l7gh3mz4jjsj6ymc6ph2a7hg6-glibc-2.21/lib/ld-linux-x86-64.so.2
-L/home/myuser/.local/opt/guix/guix/store/i901f9ad7j3cq7liaiszgpkcjs9mnw5p-libstdc++-4.9.3/lib
-o build/genmddeps \
    build/genmddeps.o build/read-md.o build/errors.o
../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a
/home/myuser/.local/opt/guix/guix/store/i3s7jv6yfcmp04qjaj2m1v3pmbw6i2qr-binutils-cross-boot0-2.25/bin/x86_64-guix-linux-gnu-ld:
cannot find -lstdc++
collect2: error: ld returned 1 exit status
Makefile:2532: recipe for target 'build/genmddeps' failed
make[3]: *** [build/genmddeps] Error 1
make[3]: Leaving directory '/tmp/nix-build-gcc-4.9.3.drv-0/build/gcc'
Makefile:4229: recipe for target 'all-stage1-gcc' failed
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory '/tmp/nix-build-gcc-4.9.3.drv-0/build'
Makefile:21597: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory '/tmp/nix-build-gcc-4.9.3.drv-0/build'
Makefile:896: recipe for target 'all' failed
make: *** [all] Error 2
phase `build' failed after 255 seconds
builder for `/home/myuser/.local/opt/guix/guix/store/g6sf7j9a6sqallf0vlkdi4l313bdi2p7-gcc-4.9.3.drv'
failed with exit code 1
@ build-failed /home/myuser/.local/opt/guix/guix/store/g6sf7j9a6sqallf0vlkdi4l313bdi2p7-gcc-4.9.3.drv
- 1 builder for
`/home/myuser/.local/opt/guix/guix/store/g6sf7j9a6sqallf0vlkdi4l313bdi2p7-gcc-4.9.3.drv'
failed with exit code 1

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Eric Bavier]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

On 2015-08-17 15:46, Claes Wallin wrote:
> On Mon, Aug 17, 2015 at 10:33 AM, Eric Bavier
> <ericbavier@openmailbox.org> wrote:
> 
>> I have experimented with this a bit lately.  It works to some extent,
>> but I have had to apply a few patches to some package recipes.  Some
>> packages have failing tests (where presumably they would pass or be
>> skipped in the chroot), which I have disabled for the time being just
>> to move along.
>> 
>> I can post a few of the patches to the ML later.
> 
> 
> Any patches related to bootstrapping gcc? I'm getting lib/lib64 
> confusion.

Yes, that's been one issue.

Attached are the patches I have so far.  Hopefully they can get you a 
bit further.  I've been able to build a number of packages, but thare 
are still some package builds failing, e.g. IIRC one of cmake's 
dependencies doesn't build.

Some of these patches may be alright in general, but turning test cases 
off is of course not an ideal solution.

-- 
`~Eric

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: unprivileged-daemon.patch --]
[-- Type: text/x-diff; name=unprivileged-daemon.patch, Size: 10348 bytes --]

diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 74c3f30..082b170 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -590,7 +590,9 @@ exec ~a/bin/~a-~a -B~a/lib -Wl,-dynamic-linker -Wl,~a/~a \"$@\"~%"
                           (if (string-prefix? "LDFLAGS=" flag)
                               (string-append flag " -L"
                                              (assoc-ref %build-inputs "libstdc++")
-                                             "/lib")
+                                             "/lib -L"
+					     (assoc-ref %build-inputs "libstdc++")
+                                             "/lib64")
                               flag))
                         ,flags)))
            ((#:phases phases)
diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index cbac16e..766c16d 100644
--- a/gnu/packages/databases.scm
+++ b/gnu/packages/databases.scm
@@ -322,7 +322,9 @@ types are supported, as is encryption.")
                                                  other-digits))
                                            6 #\0))))))
                    (string-append
-                    "mirror://sourceforge/sqlite.mirror/SQLite%20" version
+		    "http://fossies.org/linux/misc"
+;;                     "mirror://sourceforge/sqlite.mirror/SQLite%20" version
+;; 		    "http://sqlite.org/2015"
                     "/sqlite-autoconf-" numeric-version ".tar.gz")))
             (sha256
              (base32
diff --git a/gnu/packages/ghostscript.scm b/gnu/packages/ghostscript.scm
index 818072a..0492662 100644
--- a/gnu/packages/ghostscript.scm
+++ b/gnu/packages/ghostscript.scm
@@ -83,7 +83,7 @@ paper size.")
    (version "17")
    (source (origin
             (method url-fetch)
-            (uri "ftp://ftp.knackered.org/pub/psutils/psutils.tar.gz")
+            (uri "mirror://ctan/obsolete/support/psutils/psutils-p17.tar.gz")
             (sha256 (base32
                      "1r4ab1fvgganm02kmm70b2r1azwzbav2am41gbigpa2bb1wynlrq"))))
    (build-system gnu-build-system)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index ba2879f..fdecaa7 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -483,6 +483,9 @@ providing the system administrator with some help in common tasks.")
                        (("/usr/") "/")
                        (("--(owner|group) 0") "")
                        (("ldconfig") "true")
+		       (("lib64[[:blank:]]*:=(.*)$")
+			;; Make sure libs are installed in lib
+			"lib64 := lib")
                        (("^LDFLAGS[[:blank:]]*:=(.*)$" _ value)
                         ;; Add libproc to the RPATH.
                         (string-append "LDFLAGS := -Wl,-rpath="
@@ -1050,7 +1053,8 @@ advanced aspects of IP configuration (iptunnel, ipmaddr).")
                                                    (assoc-ref %outputs "out"))
                                     "RAISE_SETFCAP=no")))
     (native-inputs `(("perl" ,perl)))
-    (inputs `(("attr" ,attr)))
+    (inputs `(("attr" ,attr)
+	      ("pam" ,linux-pam)))
     (home-page "https://sites.google.com/site/fullycapable/")
     (synopsis "Library for working with POSIX capabilities")
     (description
diff --git a/gnu/packages/nettle.scm b/gnu/packages/nettle.scm
index b20ddfa..26fa81a 100644
--- a/gnu/packages/nettle.scm
+++ b/gnu/packages/nettle.scm
@@ -40,7 +40,10 @@
     (arguments
      ;; 'sexp-conv' and other programs need to have their RUNPATH point to
      ;; $libdir, which is not the case by default.  Work around it.
-     '(#:configure-flags (list (string-append "LDFLAGS=-Wl,-rpath="
+     '(#:configure-flags (list (string-append "--libdir="
+					      (assoc-ref %outputs "out")
+					      "/lib")
+			       (string-append "LDFLAGS=-Wl,-rpath="
                                               (assoc-ref %outputs "out")
                                               "/lib"))))
     (outputs '("out" "debug"))
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 940efec..1eaea4a 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -231,7 +231,7 @@ data types.")
                (base32
                 "1f4nm4z08sy0kqwisvv95l02crv6dyysdmx44p1mz3bn6csrdcxm"))))
     (arguments (substitute-keyword-arguments (package-arguments python-2)
-                 ((#:tests? _) #t)))
+                 ((#:tests? _) #f)))	;timezone name test failure
     (native-search-paths
      (list (search-path-specification
             (variable "PYTHONPATH")
diff --git a/gnu/packages/ssh.scm b/gnu/packages/ssh.scm
index f9a3a42..12f887b 100644
--- a/gnu/packages/ssh.scm
+++ b/gnu/packages/ssh.scm
@@ -109,7 +109,8 @@ remote applications.")
    ;; zlib libraries, so we need to propagate the inputs.
    (propagated-inputs `(("libgcrypt" ,libgcrypt)
                         ("zlib" ,zlib)))
-   (arguments '(#:configure-flags `("--with-libgcrypt")))
+   (arguments '(#:configure-flags `("--with-libgcrypt")
+		#:tests? #f))		;Failure in ssh2.sh test
    (synopsis "Client-side C library implementing the SSH2 protocol")
    (description
     "libssh2 is a library intended to allow software developers access to
diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
index 68f340c..3403e6a 100644
--- a/guix/build/syscalls.scm
+++ b/guix/build/syscalls.scm
@@ -312,49 +312,50 @@ string TMPL and return its file name.  TMPL must end with 'XXXXXX'."
 
 ;; The libc interface to sys_clone is not useful for Scheme programs, so the
 ;; low-level system call is wrapped instead.
-(define clone
-  (let* ((ptr        (dynamic-func "syscall" (dynamic-link)))
-         (proc       (pointer->procedure int ptr (list int int '*)))
-         ;; TODO: Don't do this.
-         (syscall-id (match (utsname:machine (uname))
-                       ("i686"   120)
-                       ("x86_64" 56)
-                       ("mips64" 5055)
-                       ("armv7l" 120))))
-    (lambda (flags)
-      "Create a new child process by duplicating the current parent process.
-Unlike the fork system call, clone accepts FLAGS that specify which resources
-are shared between the parent and child processes."
-      (proc syscall-id flags %null-pointer))))
+;; (define clone
+;;   (let* ((ptr        (dynamic-func "syscall" (dynamic-link)))
+;;          (proc       (pointer->procedure int ptr (list int int '*)))
+;;          ;; TODO: Don't do this.
+;;          (syscall-id (match (utsname:machine (uname))
+;;                        ("i686"   120)
+;;                        ("x86_64" 56)
+;;                        ("mips64" 5055)
+;;                        ("armv7l" 120))))
+;;     (lambda (flags)
+;;       "Create a new child process by duplicating the current parent process.
+;; Unlike the fork system call, clone accepts FLAGS that specify which resources
+;; are shared between the parent and child processes."
+;;       (proc syscall-id flags %null-pointer))))
 
 (define setns
-  (let* ((ptr  (dynamic-func "setns" (dynamic-link)))
-         (proc (pointer->procedure int ptr (list int int))))
-    (lambda (fdes nstype)
-      "Reassociate the current process with the namespace specified by FDES, a
+  (false-if-exception
+   (let* ((ptr  (dynamic-func "setns" (dynamic-link)))
+	  (proc (pointer->procedure int ptr (list int int))))
+     (lambda (fdes nstype)
+       "Reassociate the current process with the namespace specified by FDES, a
 file descriptor obtained by opening a /proc/PID/ns/* file.  NSTYPE specifies
 which type of namespace the current process may be reassociated with, or 0 if
 there is no such limitation."
-      (let ((ret (proc fdes nstype))
-            (err (errno)))
-        (unless (zero? ret)
-          (throw 'system-error "setns" "~d ~d: ~A"
-                 (list fdes nstype (strerror err))
-                 (list err)))))))
-
-(define pivot-root
-  (let* ((ptr  (dynamic-func "pivot_root" (dynamic-link)))
-         (proc (pointer->procedure int ptr (list '* '*))))
-    (lambda (new-root put-old)
-      "Change the root file system to NEW-ROOT and move the current root file
-system to PUT-OLD."
-      (let ((ret (proc (string->pointer new-root)
-                       (string->pointer put-old)))
-            (err (errno)))
-        (unless (zero? ret)
-          (throw 'system-error "pivot_root" "~S ~S: ~A"
-                 (list new-root put-old (strerror err))
-                 (list err)))))))
+       (let ((ret (proc fdes nstype))
+	     (err (errno)))
+	 (unless (zero? ret)
+		 (throw 'system-error "setns" "~d ~d: ~A"
+			(list fdes nstype (strerror err))
+			(list err))))))))
+
+;; (define pivot-root
+;;   (let* ((ptr  (dynamic-func "pivot_root" (dynamic-link)))
+;;          (proc (pointer->procedure int ptr (list '* '*))))
+;;     (lambda (new-root put-old)
+;;       "Change the root file system to NEW-ROOT and move the current root file
+;; system to PUT-OLD."
+;;       (let ((ret (proc (string->pointer new-root)
+;;                        (string->pointer put-old)))
+;;             (err (errno)))
+;;         (unless (zero? ret)
+;;           (throw 'system-error "pivot_root" "~S ~S: ~A"
+;;                  (list new-root put-old (strerror err))
+;;                  (list err)))))))
 
 \f
 ;;;
diff --git a/guix/download.scm b/guix/download.scm
index f0a7a29..5213338 100644
--- a/guix/download.scm
+++ b/guix/download.scm
@@ -174,6 +174,21 @@
        "http://cran.stat.auckland.ac.nz/"
        "http://cran.mirror.ac.za/"
        "http://cran.csie.ntu.edu.tw/")
+      (ctan
+       ;; Notably, we do not include the Ibiblio mirror since it
+       ;; appears to be missing any files in the "obsolete" directory.
+       "http://ctan.mackichan.com/"
+       "http://ctan.math.utah.edu/ctan/tex-archive/"
+       "http://ctan.mirrorcatalogs.com/"
+       "http://mirror.utexas.edu/ctan/"
+       "http://linorg.usp.br/CTAN/"
+       "ftp://dante.ctan.org/tex-archive/"
+       "ftp://ftp.fu-berlin.de/tex/CTAN/"
+       "http://mirrors.ircam.fr/pub/CTAN/"
+       "http://ctan.uib.no/"
+       "http://ctan.uni-altai.ru/"
+       "http://ftp.snt.utwente.nl/pub/software/tex/"
+       "http://ctan.math.ca/tex-archive/") 
       (imagemagick
        ;; from http://www.imagemagick.org/script/download.php
        ;; (without mirrors that are unavailable or not up to date)

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Claes Wallin (韋嘉誠)]

On Mon, Aug 17, 2015 at 10:57 PM, Eric Bavier
<ericbavier@openmailbox.org> wrote:

>> Any patches related to bootstrapping gcc? I'm getting lib/lib64 confusion.
>
>
> Yes, that's been one issue.
>
> Attached are the patches I have so far.  Hopefully they can get you a bit
> further.  I've been able to build a number of packages, but thare are still
> some package builds failing, e.g. IIRC one of cmake's dependencies doesn't
> build.
>
> Some of these patches may be alright in general, but turning test cases off
> is of course not an ideal solution.

Great, thanks.

My next ugly hand-cranked fix:

$ ln -s /lib64/libnss_vas4.so.2
/home/myuser/.local/opt/guix/guix/store/llnj407l7gh3mz4jjsj6ymc6ph2a7hg6-glibc-2.21/lib/libnss_vas4.so.2

As nss plugins are a system-specific configuration and
sysadmin-installed, I guess it could be argued that glibc *should*
look in the system paths for them. On the other hand, there's no
guarantee the stuff there will work for guix's glibc. In my case,
luckily it did, and coreutils could pass its tests.

Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)

[Claes Wallin (韋嘉誠)]

On Mon, Aug 17, 2015 at 10:57 PM, Eric Bavier
<ericbavier@openmailbox.org> wrote:
> On 2015-08-17 15:46, Claes Wallin wrote:
>> On Mon, Aug 17, 2015 at 10:33 AM, Eric Bavier
>> <ericbavier@openmailbox.org> wrote:
>>
>>> I have experimented with this a bit lately.  It works to some extent,
>>> but I have had to apply a few patches to some package recipes.  Some
>>> packages have failing tests (where presumably they would pass or be
>>> skipped in the chroot), which I have disabled for the time being just
>>> to move along.
>>>
>>> I can post a few of the patches to the ML later.
>>
>>
>>
>> Any patches related to bootstrapping gcc? I'm getting lib/lib64 confusion.
>
>
> Yes, that's been one issue.
>
> Attached are the patches I have so far.  Hopefully they can get you a bit
> further.  I've been able to build a number of packages, but thare are still
> some package builds failing, e.g. IIRC one of cmake's dependencies doesn't
> build.

I saw more packages failing down the line due to ../lib64, e.g.
procps, bison ... so I ended up patching gcc not to do ../lib64. Looks
neater than adding defensive -L all over the place.


How come this doesn't happen in the binary guix? Is this configuration
a thing that is perpetuated from the system to gcc, and just nobody
has been building the binary guix from scratch in a long time?

Maybe each guix release should be built from scratch (if it isn't
now), to make sure things like this don't live on unnoticed.


> Some of these patches may be alright in general, but turning test cases off
> is of course not an ideal solution.


Still compiling libcs, gettexts and gccs now. Again. I'll see if I get
far enough today to run into those issues. But I think once I get past
glibc and gcc, I ought to be on par with binary guix. Right?

Re: Running guix-daemon as an unprivileged user

[Ludovic Courtès]

"Thompson, David" <dthompson2@worcester.edu> skribis:

> Yes, user namespaces can be created by unprivileged users. The user
> that created the namespace then has root in the context of the new
> namespace, which allows for creating all of the other types of
> namespaces.  There's been some bumps along the way, such as a security
> bug with groups that prompted the addition of the
> /proc/<pid>/setgroups file in Linux 3.19 (I think) that has since been
> backported to earlier kernel releases, the oldest I know of being
> 3.13.  But overall, this feature is very good and using it for Guix
> would allow for the unprivileged daemon to take advantage of almost
> all of the isolation techniques used by the privileged daemon.

That’d be a very nice thing to have.

Thanks,
Ludo’.

Re: Running guix-daemon as an unprivileged user

[Ludovic Courtès]

Eric Bavier <ericbavier@openmailbox.org> skribis:

> On 2015-08-17 15:46, Claes Wallin wrote:
>> On Mon, Aug 17, 2015 at 10:33 AM, Eric Bavier
>> <ericbavier@openmailbox.org> wrote:
>>
>>> I have experimented with this a bit lately.  It works to some extent,
>>> but I have had to apply a few patches to some package recipes.  Some
>>> packages have failing tests (where presumably they would pass or be
>>> skipped in the chroot), which I have disabled for the time being just
>>> to move along.
>>>
>>> I can post a few of the patches to the ML later.
>>
>>
>> Any patches related to bootstrapping gcc? I'm getting lib/lib64
>> confusion.
>
> Yes, that's been one issue.

I’m afraid there are many such issues, with build systems sometimes
deciding what to do based on existence of files such as /lib64 or the
output of /usr/bin/gcc.  :-/

I really look forward to user name space support in the daemon.

Thanks,
Ludo’.