<paulproteus>
"Why does InnoDB need significant space in tmpdir? This is a new requirement with InnoDB plugin (due to online index addition only?), but I don’t see it documented anywhere"
nowhereman_ has joined #sandstorm
nowhere_man_ has quit [Ping timeout: 265 seconds]
<zarvox>
/var/tmp is not allowed to be ramdisk per FHS semantics requiring persistance across reboots
asmyers has quit [Read error: Connection reset by peer]
asmyers has joined #sandstorm
wat has joined #sandstorm
wat has quit [Ping timeout: 248 seconds]
joshbuddy has quit [Quit: joshbuddy]
_whitelogger has joined #sandstorm
<paulproteus>
Welcome _whitelogger !
<paulproteus>
I presume you're a bot, but I thought I'd say hi anyway.
<maurer>
paulproteus: Given that the ircname is "whitequark's logger bot"... :P
<paulproteus>
Well that's good evidence that it's a bot (-:
joshbuddy has joined #sandstorm
<maurer>
btw, minor nit with sandstorm - I have no idea why, but something with how the clickable apps show up on the apps list doesn't seem to work with pentadactyl's hinting system
<paulproteus>
What's pendactyl's hinting system? I'll try Googling it.
<paulproteus>
Can I get you to turn this into an issue on the GitHub issue tracker?
<maurer>
Sure, I just assumed it would be irrelevant because the list of pentadactyl users is so low :P
<paulproteus>
Yeah, but maybe it hints at some deeper accessibility issue.
<paulproteus>
Just because you file it doesn't mean we're going to fix it like immediately, don't worry (-:
<maurer>
Yeah, I'm starting to notice random nits like this since I've gotten a setup that's a little easier to drive without a mouse to avoid rsi stuff
<maurer>
So the very few things that require a mouse get noticed :P
<paulproteus>
I like the idea of Sandstorm not giving you RSI.
<paulproteus>
Thanks, that seems to be enough for geofft who is working with me on this termios thing!
<dwrensha>
Yeah, the Rust standard library doesn't provide a nice that just means "socket"
<dwrensha>
i.e. there's no equivalent of `kj::NetworkAddress`
<dwrensha>
... doesn't provide a nice *type
<maurer>
dwrensha: I suspect this may be due to windows support
<maurer>
dwrensha: Is there not a trait to encapsulate this behavior?
<maurer>
(If not, I suspect the rust guys would be amenable to such a trait)
<dwrensha>
KJ was also designed with eventual possible Windows support in mind
<maurer>
dwrensha: Sure, but my understanding is that Rust wants anything built against the rust stdlib to build and run on the big 23
<maurer>
*big 3
<maurer>
dwrensha: So I'd expect functions interacting with unix sockets to be in a separate package
<maurer>
(and since Rust doesn't do the whole open variant type thing, it'd make sense to use a trait to generate this abstraction, if it's not there already)
<dwrensha>
maurer: is there any way that you'd want to interact with a Unix domain socket that should be available for a TCP socket? or vice versa?
<dwrensha>
*shouldn't
<maurer>
dwrensha: Sending fds
<dwrensha>
ah, scm_rights
<maurer>
There might be others, but that's the first one that comes to mind
<maurer>
(hell, you might even want to send fds for capnproto in order to haul objects around without a copy)
<kentonv>
sending FDs over Cap'n Proto is actually on the wish list
<kentonv>
they would be represented as a special kind of capability
<kentonv>
at the API level, I mean
<kentonv>
the Cap'n Proto API level
<kentonv>
at the KJ level, the right interface is unclear. Windows has support for passing handles to other processes, but its API for that is really bad.
<kentonv>
unclear whether we should try to build an abstraction that covers both or just say "sorry, no handle-passing on Windows"
<XgF>
Also, you can't DuplicateHandle a socket, for extra fun
<kentonv>
wat
<XgF>
kentonv: Winsock is historically this addon module to the system, so sockets behave weirdly
<XgF>
So you have to use a special "duplicate socket" API
<kentonv>
oh, there is WSADuplicateSocket
<XgF>
If you DuplicateHandle a socket and try to use both handles, well, things break
<XgF>
Also, on Win7 and below, you have to use a whole different mechanism for passing textures between processes, but I guess we can ignore that :P
<XgF>
Also, while DuplicateHandle is nasty, so is SCM_RIGHTS
<XgF>
A result of it is that every Unix kernel has to implememt a unix socket garbage collector...
<kentonv>
we can deal with all that. The big problem is that DuplicateHandle requires the initiating process to have rights to arbitrarily destroy the other process.
<kentonv>
SCM_RIGHTS, for whatever ugliness it has, at least has sensible security semantics
<kentonv>
that works fine between mutually non-trusting parties
<XgF>
kentonv: I guess the default behavior should be that the "server" end always initiates the DuplicateHandle?
<XgF>
The other option I guess is a trusted escrow service
<kentonv>
someone has to run that escrow service, but yeah
<kentonv>
that seems better than having every server have root-ish privileges
<kentonv>
the escrow service can probably be simple enough to be auditable
<XgF>
Plus it can just vend capnp capabilities :P
<kentonv>
well, the whole point here is that we're trying to negotiate a way to pass system resources across a capnp session, because sometimes proxying over capnp is too slow.
<XgF>
kentonv: Yes, but the "escrowed handle" can be a capnp cap
<XgF>
Receiver -> HANDLE h = (HANDLE) eh.accept();
<XgF>
Nice and easy, actually
<XgF>
Tricky bit I guess is protecting the escrow service against handle exhaustion
<kentonv>
I think your interface is vulnerable to an attack in which I send you an EscrowedHandle that I implemented myself. :)
<kentonv>
so instead the interface for accepting has to be: escrowService.accept(eh)
<kentonv>
where the recipient has a preexisting trusted capability to the escrow service
<XgF>
Aah, good point :)
natea has joined #sandstorm
<XgF>
Really want to call GetSecurityInfo on the named pipe handle to the escrow service to verify its' running as somebody trustworthy also :-)
<kentonv>
XgF: the "capability-based way" would be to make sure you trust whomever gave you the pipe in the first place. Hopefully in this case that's the process parent, and if you can't trust them you're pretty screwed.
<XgF>
kentonv: If I run client.exe which is talking to a server.exe running as SYSTEM, we somehow need to agree on an escrow service to use
<XgF>
We also need to mutually trust that escrow service
natea has quit [Quit: natea]
<kentonv>
right. But if for some reason the two programs receive different escrow services, that'll be figured out pretty quick as the receiving service will refuse to recognize the capabilities from the sending service.
<kentonv>
there's not really a need to check their process identities
<XgF>
There is a need to check who is running \\.\capnp-escrow-service that I just connected to
<kentonv>
ah, you're assuming all processes find the escrow service by looking up some global name
<kentonv>
I was thinking processes would inherit the escrow service from their parent
<XgF>
You do realise that on Windows that involves DuplicateHandle'ing the escrow service handle into the child, right?
<XgF>
Never mind the parent doing another ConnectNamedPipe
<kentonv>
well, first, that's not _that_ unreasonable, although certainly ugly
<kentonv>
second, I didn't necessarily mean a handle, but rather than the parent would somehow securely identify the escrow service
<XgF>
OK. Even in that case you need to identify who's running at it, in case it's crashed or something
<kentonv>
I suppose this depends on the mechanism used to name things
<XgF>
A named pipe name only has an associated security descriptor as long as it exists, which is as long as somebody is listening
<kentonv>
I think handle passing is really the preferred approach here, at least if you're trying to do capabilities. But yeah, it's ugly. The Windows API is decidedly less capability-friendly than Unix.
<XgF>
Really, everything becomes rather unfriendly unless you do synchronous rendevousz IPC
<XgF>
(where you only transfer messages when both sender and recipient are inside the Send/Recv functions)
<kentonv>
It seems like the cycle detector in SCM_RIGHTS could be avoided in the common case...
<kentonv>
i.e. if the receiving socket end is only held by process FD tables, not in any other socket buffer, then there's no cycle
<XgF>
Most of the time SCM_RIGHTS is used its' for passing sockets over sockets :)
<kentonv>
yes but how often does the socket being passed already have nested SCM_RIGHTS messages waiting in it?
<XgF>
Quite rarely, yes
<kentonv>
that said, I think a reasonable alternative implementation would be "sending process is required to keep the FD open until the receiving process has acknowledged receipt, though whatever protocol the two choose to use". Not that it could change now.
<kentonv>
s/though/through/
<XgF>
Yeah
<XgF>
Newer designs tend to do synchronous rendevousz or similar, but thats not without its' own issues
amyers has joined #sandstorm
<geofft>
so the use case here (we're building a ptyd) is that you hold a plaintext UNIX socket, and you might want a capnp-rpc socket to do termios things to that plaintext socket
<geofft>
I'm thinking about a setup where you connect to the server socket, pass your current socket to the server, and then start speaking capnp-rpc
<geofft>
so the server receives the socket, figures out what you're referring to (... somehow), and then lets you have a conversation about it
<geofft>
is that reasonable? crazy? excessively complicated compared to something I'm not thinking of?