<worldofpeace>
IIRC opensuse can build whatever ISO they want under the sun. And everyone has these "spins". Now we don't need those because we're cool. But exposing things in a familar way to users is important.
<gchristensen>
ah
<gchristensen>
I think the concern is the ISOs are fairly large, get rebuilt quite often, and get stored essentially forever
<worldofpeace>
Well I think Opensuse can remove them, and produce iso's if only a subset of tests fail.
<gchristensen>
right
<worldofpeace>
But OpenQA has nice suite for GNOME
<worldofpeace>
Only building it for stable isn't option IMHO because people would just expect there to be an unstable iso
<worldofpeace>
But can we stop storing install ISO's forever?
<gchristensen>
they would? we don't publish unstable ISOs as it is
<worldofpeace>
Define publish. I can download an unstable iso from a link on the homepage.
<gchristensen>
I'm not sure I'd have described you as a dilettante, hah
<aszlig>
my father once called me like that, so i kept it :-D
<aszlig>
anyway, i think we can just remove the O_NOATIME flag, especially because that's the pre-4.19-behaviour, but let's see whether there is a compelling reason to use it there
<clever>
aszlig: what about a qemu flag, to make 9plan strip O_NOATIME?
<clever>
overlayfs with an ext4 lowerdir, would benefit from O_NOATIME being left in
<aszlig>
clever: that would be a workaround, i just tested NFS before and it has the same problem
<aszlig>
so it clearly is a kernel regression
<clever>
it only fails with a 9plan lower, and qemu lacking ownership
<clever>
ah, nfs would also need the same work-around...
<clever>
maybe a mount flag for overlayfs then?
<clever>
or a blacklist, dont try to do O_NOATIME when the lowerdir is nfs or 9plan?
<aszlig>
clever: ... or AFS, or GFS, or ...
<aszlig>
but IIRC there is also a function to check whether it's a networked filesystem... so that *could* be an option
<aszlig>
but i don't think they'd want to go into that direction, especially because there is work to have overlayfs to be mounted as user
<aszlig>
so the same problem will exist for local file systems
<clever>
depends on if overlayfs will respect the user perms or not, a user mounting overlayfs could be an attack to hide atime updates as you upload all the secrets on a box you owned :P
<aszlig>
although the latter can be solved by inode_owner_or_capable()
<clever>
an attacker could overlayfs / and a tmpfs together, to hide all atime updates as they scan your box
<aszlig>
clever: it will and it already does
<aszlig>
the superblock is already using the struct cred of the current user
<clever>
ah
<aszlig>
so i guess they're already preparing for that
<aszlig>
ah, i was wrong, it was FUSE that was preparing to be mounted as user
<clever>
aszlig: ive also had trouble with user namespacing, i must create a user namespace to make a mount namespace, and then i lack access to a lot of /proc/ so nix-collect-garbage (in the namespace) fails
<clever>
aszlig: so i'm forced to consider adding a pid namespace!
<aszlig>
clever: or bind-mount proc
<clever>
aszlig: i already bind-mount /proc
<clever>
but the user namespace means i lack access to the /proc of any pid outside my namespace
<clever>
the uid 1000 in the namespace isnt the real uid 1000 i think
<worldofpeace>
jtojnar: You know I did think about that as possibly being a problem. Bugfixes in update pr's are probably not great. But I thought we agreed in a way.
<aszlig>
clever: what's in uid_map within that process?
<aszlig>
but yeah, depending on the mapping you can't access proc
<jtojnar>
worldofpeace: yeah, I noticed the issue when we started discussing the PR there; and remembered the times scrolling the 3.20 issue and clicking load more comments repeatedly
<clever>
aszlig: pid 325 is a chrome proccess on the host
<worldofpeace>
jtojnar: right, moving it out 👍
<jtojnar>
worldofpeace: I am starting to thing, as much as I hate merge commits, that our rebases make the github history even less legible, we need better tooling
orivej has quit [Ping timeout: 245 seconds]
<worldofpeace>
jtojnar: Define legible? git history for package repo's tend to take certain form.
<jtojnar>
I mean mostly the comments
<worldofpeace>
Yeah , in progress the discussion of what happened to get x change is just completely gone.
<aszlig>
clever: (takes a while, trying this in my own sandbox implementation, where i remember that it worked without pid namespaces)
<clever>
aszlig: i'm also warry about adding pid namespacing, because then i may have different pid namespaces on the same fake root, and then nix-store --query --root cant see the other pid namespaces
<clever>
aszlig: $$ is causing the containerized bash pid to be inserted
<aszlig>
yep
<clever>
aszlig: if i replace it with the pid of something outside the namespace, it fails the same way nix-user-chroot does
<aszlig>
clever: aaah...
<aszlig>
i thought you meant within the namespace
<aszlig>
sorry
<clever>
but the uid map claims i still own 325
<aszlig>
hm, so why not using a control socket or pipe that handles GC from outside the namespaces?
<clever>
aszlig: the container has its own /nix/store
<clever>
aszlig: the goal is to have fully working nix, with binary cache support, when i lack write access to /
<aszlig>
okay, and you obviously don't want paths to be GCed when they're used from outside the container
<clever>
aszlig: nothing outside the container should be using those paths, but there is the tricky issue is using the same pid namespace if i enter it twice
<clever>
(if i add pid namespacing)
<aszlig>
clever: hm, what about setns?
<clever>
its more about finding out of an existing namespace is there, or if one should be made, when entering
<aszlig>
clever: and you want to avoid pidfiles and stuff like that, right?
<clever>
pid files and such would be fine, though are complicated by pid namespaces, and nesting containers
<aszlig>
well, IIUC you just need to make sure it's not written from within the pid namespace
<clever>
but if i re-run the enter tool, from inside the namespace, it will fail to find the pid in the file
<clever>
and then try to create a namespace, inside the namespace
<aszlig>
ah
<clever>
but, i have also had EPERM failures, if i try to make a namespace, inside the namespace
<clever>
originally, i solved that by detecting my own install util, and unpacking it
<clever>
but then i ran into xdg-open problems (steam also has this issue)
<clever>
so i added an escape-hatch fifo
<clever>
if you print any string to /escape-hatch, the util that created the namespace will just execute that string, outside the namespace!
<clever>
it cant find any browser inside the sandbox, and fails to open the link!
<clever>
the steam sandbox could use some escape-hatches
drakonis has quit [Ping timeout: 240 seconds]
* clever
heads off to bed
drakonis has joined #nixos-dev
<matthewbauer[m]>
clever: how do other containers handle this? the escape hatch thing always seemed like a bad hack to me but I could never think of a better solution
<aszlig>
speaking of sandboxing, just updated the description of #57519
drakonis_ has quit [Remote host closed the connection]
orivej has joined #nixos-dev
pie__ has quit [Remote host closed the connection]
pie__ has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
init_6 has joined #nixos-dev
orivej has joined #nixos-dev
jtojnar has joined #nixos-dev
<aszlig>
samueldr: given that we got rid of the overlayfs issue (well, patch still needs to be applied, ideally upstream), do you think we can get it in 19.03?
<aszlig>
s/\<it\>/kernel 4.19/
<samueldr>
I was lightly thinking about it yesterday evening, and I don't know for sure
<samueldr>
we're about halfway in the stabilisation period, so hmm, it'd be annoying if it brought issues
<samueldr>
but on the other hand, it does bring issues to default to an older kernel (for newer hardware mostly)
<samueldr>
thinking about the installation media
<aszlig>
samueldr: well, halfway is better than at the end of that period :-)
<samueldr>
definitely
<aszlig>
i could however add that patch to master already... so far there hasn't been opposition on the upstream part
<aszlig>
and the patch basically gets to the same behaviour as pre-4.19
<samueldr>
make the PR with the swtich to LTS so the test suite runs on it, maybe?
<aszlig>
omw...
nbp has joined #nixos-dev
<aszlig>
samueldr: first just the overlayfs patch for master
<aszlig>
samueldr: i'll add a follow-up PR with the cherry-pick of that plus the LTS
<nbp>
I think Nix should remove the read-flag of the /nix/store directory, such that we can really claim to have a security by obfuscation model.
<nbp>
I think you only need the 'x' flag on a directory to traverse it.
<aszlig>
nbp: this was the case for a short period of time already, but got reverted
<aszlig>
although it did have read permissions for "others"
<nbp>
hum … are our test well written then ?!
<aszlig>
nbp: i have no idea what was *exactly* broken as the commit doesn't say so, but I'd imagine it's one of the path-verification subtests
<ekleog>
nbp: FWIW your file system probably allows enumeration of paths in a non-readable directory via side-channels
<aszlig>
nbp, ekleog: not only that, but you can also enumerate them via /nix/var/nix/db/db.sqlite
<nbp>
ekleog: sure, if you are root.
<nbp>
aszlig: which is only supposed to be opened by the nix users / nix deamon?
<aszlig>
supposed to be opened, but right now it's world-readable
<ekleog>
nbp: not only if you are root, I think the -r flag on directories can likely be bypassed via side-channels -- without experimenting precisely with it, though
drakonis has joined #nixos-dev
<aszlig>
i do however see an advantage in that, but not from a security perspective
<aszlig>
there are a bunch of applications out there that readdir every path component and they become horribly slow when you have a large store
<{^_^}>
#57519 (by aszlig, 2 days ago, open): nixos: Add 'chroot' options to systemd.services
<clever>
ooo, that sounds fun
<clever>
aszlig: dont forget about /usr/bin/env
<aszlig>
clever: i'd rather avoid that, because that's easy to patch
<clever>
yeah, env can just be patched out in things
<clever>
but /bin/sh is a requirement of libc! cant patch that out
<aszlig>
clever: the /bin/sh case is much harder
<aszlig>
i do agree with niksnut there that maybe it's better to use bash as /bin/sh by default to not confuse users
<aszlig>
but i also want to have an *option* to make it more restrictive
<ekleog>
aszlig: `assert(argc > ?); argv[2] = NULL; execve(argv[1], argv, envp);` (with ? a number I can never remember because I never remember whether there's an off-by-1 in argc)
<aszlig>
aszlig: ah, what's the context?
<clever>
if a program is ran with zero arguments, then argc == 1, because argv[0] is the programs own name
<clever>
argv will always be one higher then the last valid slot in argv
<aszlig>
lol
<aszlig>
<aszlig> aszlig: ... yah! talking to myself, retry:
<aszlig>
ekleog: ah, what's the context?
<ekleog>
aszlig: your question of something that only allows `sh -c something` with `something` that should be something minimal
<ekleog>
unless I misunderstood
<aszlig>
ekleog: ah, not the "something" should be something minimal, but /bin/sh itself
<aszlig>
it shouldn't be a real shell
<clever>
which would break #!/bin/sh and force people to patch things even more!
<aszlig>
and also exit with failure if it's not used with -c foo
<aszlig>
clever: that's the goal
<clever>
it could be a muslc binary that only supports -c
<clever>
i remember a very weird bug i helped someone diagnose, many years ago
<clever>
they had the binary cache disabled, and glibc failed to build
<clever>
because when building glibc, no output of glibc is allowed into the nix sandbox
<clever>
and then /bin/sh cant find glibc
<aszlig>
hm... thinking about that, i could probably defer this...
<aszlig>
like eg. confinement.binSh = null; <- for no /bin/sh
<ekleog>
aszlig: hm guess I misunderstood the question then
<clever>
if sh was a static binary, the above issue cant happen
<aszlig>
or binSh = someshell
<aszlig>
so the type is nullOr path
ajs124 has joined #nixos-dev
<aszlig>
clever: hm, i also think that your point with /usr/bin/env is probably a good idea as well, at least by default
<aszlig>
because even though i *personally* would want to not provide it, unconfined services do have access to it
jtojnar has quit [Quit: jtojnar]
johanot has quit [Quit: WeeChat 2.4]
<gchristensen>
ekleog, can you send me some dates and times you're available to talk about the RFC?
<ekleog>
gchristensen: follow-up in PM if that's OK?
<samueldr>
(I mean, I wanted to suggest it might be some low timeout value, but it didn't make sense to me they would do that for such a low threshold)
<gchristensen>
me too....
<LnL>
gchristensen: what about the first one? from the title I'd think those are actual 503 responses from s3