|
what inputs does the attacker control?
|
#
?
Dec 12, 2014 20:04
|
|
|
|
| # ? May 27, 2024 00:00 |
|
|
Possibly the UID, GID, and PID of the program, which you can check for in a ruleset. PolicyKit is just an authorization rule checker with the option to prompt the system for a password. Even if you crash it, nothing bad happens.
|
|
#
?
Dec 12, 2014 20:10
|
|
|
Suspicious Dish posted:Yes. How would you recommend we interpret the C language in a safe and secure way to evaluate a complex ruleset? I don't understand why you would want to
|
|
#
?
Dec 12, 2014 20:24
|
|
|
Suspicious Dish posted:Possibly the UID, GID, and PID of the program, which you can check for in a ruleset. PolicyKit is just an authorization rule checker with the option to prompt the system for a password. Even if you crash it, nothing bad happens. datalog
|
|
#
?
Dec 12, 2014 20:45
|
|
|
Ludwig van Halen posted:I don't understand why you would want to Because system administrators wanted to have complex action authorization rulesets.
|
|
#
?
Dec 12, 2014 20:50
|
|
|
what uses polkit besides the clock control panel?
|
|
#
?
Dec 12, 2014 20:51
|
|
|
yeah the legions of desktop linux janitors out there
|
|
#
?
Dec 12, 2014 20:52
|
|
|
there must be tens, if not dozens
|
|
#
?
Dec 12, 2014 20:53
|
|
|
why bother with other languages in a post-C world?
|
|
#
?
Dec 12, 2014 21:29
|
|
|
Ludwig van Halen posted:why bother with other languages in a post-Go world?
|
|
#
?
Dec 12, 2014 21:30
|
|
|
Notorious b.s.d. posted:what is this if you store a closure (such as a callback or event handler), it can capture referenced objects for the lifetime of the closure, which is often the lifetime of the program. if there are unmanaged references involved, you can end up with undetected cycles and uncollected garbage much like my posting
|
|
#
?
Dec 12, 2014 23:58
|
|
|
Yes, but we explicitly collect and destroy the JS Context after running one script. We're very aware of closures building reference cycles.
|
|
#
?
Dec 13, 2014 00:41
|
|
|
Suspicious Dish posted:Yes, but we explicitly collect and destroy the JS Context after running one script. We're very aware of closures building reference cycles. that's the trap! the JSContext is the thread of execution, it's the object graph that matters. they're often reused out of performance concern, which leads to the problem. I'll stop short of turning this into the PL thread, and try to remember to just take a look at the code at some point.
|
|
#
?
Dec 13, 2014 01:05
|
|
|
My understanding was that destroying a JSContext would mark all objects rooted in that context, including the global object, as dead, and run a full mark/sweep GC. Since nothing is keeping the closure alive (all references to it come from the global object, which is now dead), it gets collected.
|
|
#
?
Dec 13, 2014 01:12
|
|
|
Suspicious Dish posted:My understanding was that destroying a JSContext would mark all objects rooted in that context, including the global object, as dead, and run a full mark/sweep GC. Since nothing is keeping the closure alive (all references to it come from the global object, which is now dead), it gets collected. objects are not rooted in a context, the JSContext * parameter is just to find the runtime; see also JS_AddRootRT.
|
|
#
?
Dec 13, 2014 09:06
|
|
|
linux
|
|
#
?
Dec 14, 2014 20:46
|
|
|
pram posted:linux the linux desktop: now inseparable from nodejs
|
|
#
?
Dec 14, 2014 21:09
|
|
|
linux-vomica
OldAlias fucked around with this message at 21:14 on Dec 14, 2014 |
|
#
?
Dec 14, 2014 21:10
|
|
|
Notorious b.s.d. posted:the linux desktop: now inseparable from nodejs hmm, maybe dbus should be reimplemented using node.js as part of systemd someone should suggest it to Debian and Canonical
|
|
#
?
Dec 14, 2014 22:32
|
|
|
eschaton posted:hmm, maybe dbus should be reimplemented using node.js as part of systemd just get drunk with lennart and it will be magically funded by redhat no "democracy" required
|
|
#
?
Dec 14, 2014 22:33
|
|
|
when is the year of ubuntu on the phone?
|
|
#
?
Dec 14, 2014 22:33
|
|
|
I mean, why not just restructure all IPC around http and JSON? seems like it'd fit the Unix philosophy quite well.
|
|
#
?
Dec 14, 2014 22:34
|
|
|
lol forgot about that. literally pissing money into the void
|
|
#
?
Dec 14, 2014 22:35
|
|
|
rrrrrrrrrrrt posted:when is the year of ubuntu on the phone? maybe the year is in china
|
|
#
?
Dec 14, 2014 22:36
|
|
|
ubuntu phone vs firefox phone. which is the more massive misallocation of resources
|
|
#
?
Dec 14, 2014 22:37
|
|
|
eschaton posted:I mean, why not just restructure all IPC around http and JSON? seems like it'd fit the Unix philosophy quite well. docker does http and json over a unix socket
|
|
#
?
Dec 14, 2014 22:37
|
|
|
whats wrong with http over a unix socket
|
|
#
?
Dec 14, 2014 22:39
|
|
|
pram posted:whats wrong with http over a unix socket nothing, i guess it's just an example of the phenomenon eschaton predicted
|
|
#
?
Dec 14, 2014 22:40
|
|
|
it has less overhead than tcp
|
|
#
?
Dec 14, 2014 22:41
|
|
|
Notorious b.s.d. posted:the linux desktop: now inseparable from nodejs re-implement systemd using nodejs!
|
|
#
?
Dec 14, 2014 23:45
|
|
|
unix ipc is so poo poo that the only useful ipc primitive right now is technically part of the networking subsystem hoping kdbus, er, kdbusfs, gets merged soon! now instead of being part of the networking system the primary ipc mechanism will be part of the filesystem layer! (i understand why, namespacing and access control and poo poo, not saying it's a bad thing, just a funny outcome of ~*the unix philosophy*~) i'm actually doing an embedded-ish thing that uses dbus as its middleware atm (the embedded-ish thing is not a car). suits teh needs. also being able to control most linux poo poo via dbus in addition to my processes is a plus.
|
|
#
?
Dec 14, 2014 23:50
|
|
|
lol at using dbus
|
|
#
?
Dec 14, 2014 23:55
|
|
|
whats wrong with named pipes huh
|
|
#
?
Dec 14, 2014 23:55
|
|
|
unix sockets and named pipes should be good enough for anyone
|
|
#
?
Dec 14, 2014 23:56
|
|
|
Mr Dog posted:unix ipc is so poo poo that the only useful ipc primitive right now is technically part of the networking subsystem At least there is a usable IPC unlike other platforms ...
|
|
#
?
Dec 15, 2014 00:07
|
|
|
Mr Dog posted:unix ipc is so poo poo that the only useful ipc primitive right now is technically part of the networking subsystem this is one reason Mach rules, actual not-suckful IPC, with reasonable namespacing, on-demand launching, etc.
|
|
#
?
Dec 15, 2014 00:53
|
|
|
pram posted:ubuntu phone vs firefox phone. which is the more massive misallocation of resources im gonna say firefox op
|
|
#
?
Dec 15, 2014 01:28
|
|
|
eschaton posted:I mean, why not just restructure all IPC around http and JSON? seems like it'd fit the Unix philosophy quite well. worse is better
|
|
#
?
Dec 15, 2014 01:37
|
|
|
Soricidus posted:worse is better Gnome already tried that with CORBA and Orbit, you can't really beat that for being worse.
|
|
#
?
Dec 15, 2014 01:48
|
|
|
|
| # ? May 27, 2024 00:00 |
|
|
pram posted:unix sockets and named pipes should be good enough for anyone those are transport layer no
|
|
#
?
Dec 15, 2014 02:01
|
|
