<clever>
is that one of those scripts with 5 lines of shell code and 20gig of raw binary appended to it?
<clever>
it would be better to add /bin to $PATH, then to do /bin/rm every single time you need rm, it makes it more portable, and it it saves 5 bytes per command
<clever>
both assume that shell script authors are sane and obey $PATH
<clever>
nix-env puts things into ~/.nix-profile/bin/ and nix-shell updates $PATH
<clever>
most of those are probably in coreutils, which is always installed
<clever>
yeah
<clever>
its already in $PATH
<clever>
drp: just use sed to change /bin/rm to rm
<clever>
no more "but it works for me"
<clever>
you can then fill it in with overrides, that other devs will automaticaly get, when they clone the project
<clever>
this will load nixpkgs, and tell it to use {} for the config, and ignore the file
<clever>
import <nixpkgs> { config = {}; }
<clever>
i always disable that though, it can lead to "but it works for me" situations
<clever>
Svarog: oh, and it will also change where ~/.config/nixpkgs/config.nix is looked for
<clever>
not much will check /etc/passwd
<clever>
that will affect everything that just reads $HOME
<clever>
s/somes/sometimes/
<clever>
Svarog: something i somes do is something like HOME=/home/clever/fake-home nix-shell -A ...
2017-04-22
<clever>
samae: and if it was done in a systemd.services, it would probably make a bar.baz.service
<clever>
it creates an attribute called bar.baz, which is different from foo.bar.baz = value;
<clever>
which can lead to confusing errors
<clever>
nix also lets you do foo."bar.baz" = value;
<clever>
mitchty: i think nix-buffer basicaly just runs nix-shell within one of emacs's terminals, but i still havent broken my vim addiction, lol
<clever>
mitchty: nix will skip development files when installing things, you want nix-shell -p zlib
<clever>
joepie91: and all on the same private lan, so they can emulate 3 real servers working together over the internet
<clever>
joepie91: one use-case of containers ive had recently, was spawning 3 nixos containers, each with identical custom modules, that had their own nginx:80, and mysql unix socket
<clever>
steveeJ: this forces it to not snapshot the path
<clever>
nix-repl> builtins.toString ./.
<clever>
"/home/clever"
<clever>
steveeJ: so you will get a copy of the directory, rather then the original path
<clever>
steveeJ: if you just directly use it (say like "${./.}") then nix will force a snapshot of that directory into /nix/store (if it isnt already there)
<clever>
steveeJ: yeah
<clever>
steveeJ: that would be relative to the file its in, rather then the file on the cmdline
<clever>
steveeJ: you can get it by manipulating ./. in a nix expression
<clever>
dupin: i usualy try to limit how much it can free, because it will wreck the cached data from a partialy ran nixos-rebuild, forcing you to re-download it all
<clever>
dupin: you can also re-run it, with bigger numbers, to free up as much as you want
<clever>
spacefrogg: truncate file -s 0
<clever>
spacefrogg: the truncate command can also do that
<clever>
though zfs still wont like that, it cant do in-place changes to dir metadata
<clever>
ah, and optimize may work even with 0 bytes free, since its making hardlinks and deleting
<clever>
dupin: does this command help some?, "nix-collect-garbage --max-freed 10M"
<clever>
yeah
<clever>
yeah
<clever>
bennofs: looks like the python stuff is disabled in hydra, but if you over-eval, you may catch python that was in the closure of other stuff, and built anyways
<clever>
you might also be able to use the json from one of the hydra utils
<clever>
ahh, so it skips hydra and directly evals
<clever>
ah
<clever>
combine the 2, and you have every file in an eval, from all passing jobs
<clever>
hydra has a url that will spit out every storepath in a given eval (built or not), and the binary cache has .ls files for every storepath in the cache
<clever>
bennofs: dang!
<clever>
bennofs1: ah, is it scanning the .ls files and making a programs.sqlite like db without any filter?
<clever>
spacefrogg: i have written systemd services before that are on the receiving side of it
<clever>
spacefrogg: i cant see why it wouldnt work elsewhere, but it may need a custom c program to open the unix socket and pass it via the correct fd#
<clever>
bennofs1: ive been wanting that as well, every time the power goes out, it takes the network switch with it, and i have no way to do a clean shutdown
<clever>
yeah
<clever>
ah, so its actualy receiving a pre-opened socket as its started
<clever>
but how is the dbus.service file telling dbus to use that path?
<clever>
spacefrogg: what was the argument for dbus, to tell it which socket to use?
<clever>
bennofs1: multiple sessions in a single user, using different $HOME values to fake different users
<clever>
spacefrogg: i want to be able to spawn multiple instances of the program, without needing seperate users
<clever>
bennofs: mainly by changing $HOME, and clearing all dbus related variables, so it forms a new session that is cut off from the rest
<clever>
bennofs1: but kmscon has internaly saved the broken state of tty1, so alt+f1 restores the breakage
<clever>
bennofs1: i also have kmscon, and have found that ctrl+alt+f1 from xorg->"tty1" breaks the gpu, i then have to alt+f2 to get kmscon to re-initialize it
<clever>
bennofs1: but if kms isnt working 100%, sysrq+k will bork the gpu state, and now you need to reboot
<clever>
bennofs1: yep
<clever>
unlmtd[m]: linux has a similiar thing under sysrq, that will -9 everything in the current tty
<clever>
unlmtd[m]: windows made it such that ctrl+alt+del cant be captured by normal programs, and always brings up a trustable gui
<clever>
unlmtd[m]: in my mind, if you can sign the kernel and rootfs, and the os within never runs untrusted files, there is no need to sign the binaries inside the rootfs
<clever>
unlmtd[m]: i'm signing the rootfs image, but the binaries within are fully unsigned
<clever>
unlmtd[m]: my original goal was to have firmware like images for an embeded server cluster
<clever>
unlmtd[m]: ah, i just have signed boot with a read-only fs and sshd
<clever>
unlmtd[m]: the kernel, initrd, and rootfs are all signed with a cert and keypair, and the cert is embeded into the ipxe binary
<clever>
bennofs1: i believe the systemd-user daemon gets started by pam, as a child of the process doing the login (your display-manager, after it dropped root to your user)
<clever>
bennofs1: yeah, but i havent been able to find an option to just turn it off
<clever>
ekleog: kms allows the kernel to restore text-mode in the event of xorg crashing, or a kernel panic needing to display the error
<clever>
ekleog: and before kms (kernel mode switchin) was a thing, xorg would just hijack the entire gpu and make destructive mode changes, such that the kernel cant recover if xorg ever quits un-cleanly
<clever>
ekleog: want to place bets you can just tweak the address a bit, and get arb write to any memory address? lol
<clever>
ekleog: oh yeah, and some GPU drivers are implemented by just mmap'ing chunks of physical ram into xorg, or possibly the opengl clients
<clever>
bennofs1: to start in certain session modes
<clever>
bennofs1: and the whole reason i was using the sandbox was to avoid needing an xorg server
<clever>
bennofs1: for example, i cant even start pulseaudio in a sandbox, because it needs dbus, and dbus needs x11
<clever>
bennofs1: yeah, ive found dbus to just be a giant pain
<clever>
ekleog: oh, and libredirect also was breaking chromium, that fix also made it into that commit
<clever>
ekleog: it had to be patched to look in /run/wrappers/bin
<clever>
ekleog: nix doesnt allow any setuid programs in /nix/store, and chromium expects the setuid program to be in $out
<clever>
bennofs1: oh correction, grsecurity, not selinux
<clever>
bennofs1: as for why selinux did it, to reduce the attack surface area, non-root rarely needs that code, turning it off is simpler then auditing
<clever>
bennofs1: that broke chromium security a while back
<clever>
bennofs1: ah, but i did also hear about how selinux locks namespaces like that down to only root
<clever>
joepie91: and at that point, i can make my own /etc/shadow, pop in a copy of sudo, and i have root!
<clever>
joepie91: i have also been interested in how nixos can possibly implement FHS user envs safely, it appears to be a setuid wrapper that just runs X under root Y
<clever>
bennofs1: i would expect that to have been disabled, along with /dev/mem
<clever>
joepie91: so you just open a crap-ton of files and make that fail
<clever>
joepie91: part of the exploit, is that the setuid program will check /proc/filesystems to see if fuse.ko needs to be loaded or not
<clever>
joepie91: and also, by default, sudo on some distros will heavily sanitize the env
<clever>
joepie91: id blame the fuse guys for not knowing about that edge-case in setuid
<clever>
joepie91: modprobe was never designed to be used via setuid stuff, and fuse didnt sanitize the environment enough
<clever>
joepie91: and that config can say "just run X instead of loading fuse.ko"
<clever>
joepie91: and modprobe will obey an env variable as for what config to obey
<clever>
joepie91: and that setuid program will "modprobe fuse" if fuse isnt loaded
<clever>
joepie91: when you try to mount something via fuse, it will use a setuid wrapper to do the actual mounting
<clever>
joepie91: that reminds me of a fuse exploit
<clever>
bennofs1: or row-hammer?
<clever>
ekleog: oh, and nix can also use some namespace features to change the hostname inside a sandbox, and even claim the cpu is 32bit only
<clever>
ah, so the age may have helped to fix all of the bugs
<clever>
joepie91: vs mainline linux containers
<clever>
joepie91: and how well tested are such hacks?, might it actualy be worse then containers?
<clever>
ekleog: nix also uses all of those namespace features to implement its build sandboxes
<clever>
joepie91: and you need a way to enforce pages from container#1 only going into the swapfile made by container#1
<clever>
joepie91: id still consider swap files to be a potential privledge esclation exploit, if any kernel side datastructures get swapped out, you can modify them
<clever>
joepie91: turns out, root can be denied permission to swapon, lol
<clever>
joepie91: i have helped somebody on an openvz guest with abnormaly low ram, i tried to show him how to make a swapfile
<clever>
ekleog: network namespacing allows different services to all bind to the same port, and not collide
<clever>
ekleog: pid namespacing blocks ps aux from seeing things outside of the container, uid namespacing can dynamicaly remap uid's, so the container may think it has 0, but it doesnt
<clever>
ekleog: about the only thing ive seen containers have, that you cant already get via chroot and drop-root, is things like pid/uid/mount/network namespacing
<clever>
ekleog: systemd was doing chmod -1 on a file, causing a state file to be both world writable (777), and setuid root
<clever>
ekleog: yeah, though systemd did have a related bug a few months ago
<clever>
simpson: and i believe it could be configured to give isolation just as good as containers
<clever>
simpson: this heavily restricts what updatedb can read and/or write to
<clever>
eacameron: but with nix, you can have as many libc's as you want, so there is no need for a second rootfs or docker
<clever>
eacameron: yeah, an example of something that typicaly needs docker, messing around with musl, there can only be 1 /lib/libc.so, and you cant just swap glibc out for musl
<clever>
eacameron: or when i want to give potentialy untrust-worthy code shell access
<clever>
eacameron: the only time i ever need a container, is when a service will collide with itself (fighting over a port or unix socket), and i need 2 instances of it running
<clever>
dmj`: that would combine bullet points 1 and 3
<clever>
dmj`: i can also see how not-os could be tweaked a bit to make a ~40mb docker container
<clever>
offsite*
<clever>
maybe zfs send if you want offset copies
<clever>
sphalerite: zfs snapshots if you want local archives of changes
<clever>
LnL: 17.03 darwin isnt that important, so we can just ignore it
<clever>
sphalerite: yeah, its more for software i'm writting, and i'm building all of the new changes around nix and nixops
<clever>
LnL: ah, so its still older
<clever>
sphalerite: stop the mumble daemon, delete the new dir it made, copy things over, and start it back up
<clever>
sphalerite: in the case of mumble, yeah, i would just manualy copy it over
<clever>
then i can just sign into a gui over http, pick a recent backup, and click restore
<clever>
sphalerite: my plans are to modify the application so it can push/pull state backups from a central location
<clever>
sphalerite: you want hardeningDisable="format"; in the derivation
<clever>
GiGa|Laptop: try booting it back up, and then see if hdd activity starts when you just click the power button, it may still be able to do a clean shutdown
<clever>
GiGa|Laptop: did you click the power button once to recover it?, or hold the power button?
<clever>
mojjo: and an extra copy of the interactive in /etc/bashrc
<clever>
mojjo: it looks like bash will put both of those into /etc/profile
<clever>
GiGa|Laptop: thats odd, how far along does the boot seem to get when you watch it?
<clever>
GiGa|Laptop: or just "journalctl -b -1 | gist -p" to send the whole thing to a gist
<clever>
GiGa|Laptop: then search thru that for things related to display-manager
<clever>
GiGa|Laptop: "journalctl -b -1" will show the entire log from the previous boot until shutdown
<clever>
GiGa|Laptop: ah, that might be different, are you able to boot an older nixos via grub and then inspect the journal?
<clever>
gchristensen: it has a shell script in the root that will tell you what perl packages are missing, but the apt package name isnt always obvious, and i had to cpan at least a dozen modules
<clever>
gchristensen: it took me about 12 hours to get that to work on ubuntu, lol
<clever>
gchristensen: oh god, that mess, lol
<clever>
GiGa|Laptop: a recent change broke every display manager except sddm
<clever>
luckily, win7 still boots if you chainload the MBR, but i havent actualy booted it in over a year
<clever>
so it refused to boot legacy linux until i just shut off efi support
<clever>
Yaniel: i also found that my bios totally ignored the boot priority, until i turned efi off entirely
<clever>
jophish: have you seen my ideas on how to give nixops support for any datacenter that allows root and an MBR?
<clever>
Yaniel: "/run/current-system/bin/switch-to-configuration boot", and make sure /boot and any efi things are mounted correctly inside the chroot
<clever>
Yaniel: might be simpler to just redo the bootloader without nixos-rebuild then, one sec
<clever>
Yaniel: what args did you run it with?
<clever>
if you dont use --chroot, it will use the channels on the installer, and might downgrade (or upgrade) the entire os
<clever>
if you use --chroot, then it will obey the channels inside the install
<clever>
Yaniel: so if the channel in the installer is reasonable, you can just do that directly
<clever>
Yaniel: also, nixos-install by default, will just nix-build the configuration, then install the bootloader again
<clever>
jophish: there are also other neat things like that just hidden all over the place and undocumented
<clever>
it runs autoreconf before doing ./configure
<clever>
the autoreconfHook i gave someone a few minutes ago is another
<clever>
anything you add to the inputs can mutate the bash variables/functions in the environment, and change how the build is done
<clever>
jophish: this is how adding cmake to the inputs causes cmake to hijack the configurePhase
<clever>
jophish: and the stdenv will source that if its found in the buildInputs
<clever>
jophish: makeSetupHook will just copy the script to $out/nix-support/setup.sh
<clever>
jophish: currently, its a setup hook you have to add to the buildInputs of a package
<clever>
:D
<clever>
jophish: sure :)
<clever>
jophish: and if configured right, it will cause an armv6 build to fail if it makes v7 opcodes
<clever>
jophish: this hook will use the arm builds of binutils (x86 build doesnt work) to read the arch specific elf headers, and check for armv7 opcodes
<clever>
jophish: ive been wanting to make a pr with it for ages, but keep forgetting to do it
<clever>
jophish: being runtime also opens up some more portable stuff, you could make an armv6 nix build, that works on v6, v7l and aarch64, and is capable of running builds for all 3
<clever>
jophish: yeah, make it a runtime config, and then the admin can just set it right
<clever>
jophish: so your patch would break on the aarch64 build slaves
<clever>
jophish: gchristensen mentioned that the aarch64 build slaves for hydra dont have v6 or v7 support, no ability to run 32bit code
<clever>
jophish: my variant will make it a nix.conf entry, so you can change it after building
<clever>
gchristensen: did you hear of the sddm issue from yesterday?
<clever>
hyphon81: heading out now, i'll be back in about 1 or 2 hours
<clever>
hyphon81: i can just ask the ipfs network who has build z?, and i get a list of IP's i can freely exploit
<clever>
hyphon81: and because of how ipfs works, i dont even have to portscan to find out who has an old version of y
<clever>
hyphon81: and then somebody can look up any exploits for that version, and even test it, because nix lets them get an exact copy of it
<clever>
hyphon81: oh, and there is a secondary problem with ipfs, if you share what you currently have, you are broadcasting to the world, "i have version x of program y"
<clever>
hyphon81: the existing signing stuff can be improved to ensure you only ever get trusted code
<clever>
Svarog: the signing will be done by nix-daemon