summaryrefslogtreecommitdiff
path: root/hurd/translator/proc.mdwn
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@codesourcery.com>2014-02-26 15:20:53 +0100
committerThomas Schwinge <thomas@codesourcery.com>2014-02-26 15:20:53 +0100
commit93060a3967ef66873d6246b0b1228c57aed2d9e4 (patch)
tree0dda55d9eaa0fdf687acc80ac2329bdf42c6a652 /hurd/translator/proc.mdwn
parentca63bd2d33b3d28eabd50ad58577b52a1fc9eba0 (diff)
parentc4ad3f73033c7e0511c3e7df961e1232cc503478 (diff)
Merge remote-tracking branch 'feldtkeller.SCHWINGE/master'
Conflicts: news/2011-q2.mdwn open_issues/glibc.mdwn open_issues/versioning.mdwn
Diffstat (limited to 'hurd/translator/proc.mdwn')
-rw-r--r--hurd/translator/proc.mdwn68
1 files changed, 67 insertions, 1 deletions
diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn
index b3b5e703..924abc99 100644
--- a/hurd/translator/proc.mdwn
+++ b/hurd/translator/proc.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation,
+Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -78,3 +79,68 @@ It is stated by `/hurd/init`.
< braunr> teythoon: i agree with you on proc process-to-task mapping
< braunr> that's something i intend to completely rework on propel
< braunr> in a way similar to how pid namespaces work on linux
+
+
+# PID "Races"
+
+## IRC, freenode, #hurd, 2014-01-26
+
+ <quotemstr> Does Hurd have anything that generally solves PID races?
+ <youpi> what kind of race are you thinking about?
+ <youpi> I'm not sure, but I guess keeping a reference to a task port will
+ prevent the proc server from recycling the corresponding pid
+ <quotemstr> Yep.
+ <quotemstr> How does the Hurd avoid the obvious denial-of-service attack
+ that results?
+ <youpi> well quotas would probably be enough
+ <youpi> that's not a new issue :)
+ <quotemstr> Fair enough.
+ <quotemstr> Returning to the POSIX-y world after a few year stint over in
+ NT-land, it's infuriating that it's still not possible to write a
+ reliable killall(1) under Linux or the BSDs.
+ <quotemstr> I'm glad Hurd solves the problem. :-)
+ <braunr> but it doesn't
+ <braunr> how can you write a reliable killall ?
+ <youpi> so keeping a reference to the task port is not enough?
+ <braunr> i'm not sure
+ <braunr> first i'd like quotemstr to clearly define the reliability problem
+ of killall
+ <quotemstr> braunr: The possibility that a PID might be used between the
+ time you decide to kill it and the time you actually kill it.
+ <braunr> well, it would have to wrap around for that
+ <quotemstr> braunr: So? It's possible.
+ <braunr> i guess that's what you refer to
+ <braunr> ok
+ <braunr> well yes, it's possible to easily create a routine that atomically
+ increases the number of references on a task/process when looking it up
+ <braunr> preventing its removal from the list of processes reported by the
+ proc server
+ <quotemstr> Like OpenProcess? :-) Would this reference count be
+ automatically decremented if the task owning the reference is killed?
+ <braunr> it would clearly not be a "posixy killall" then, but i suppose we
+ don't care about that at all
+ <braunr> no
+ <quotemstr> Oh.
+ <braunr> destroying an object doesn't remove its references
+ <quotemstr> So it's possible to leak the reference and prevent reuse of
+ that PID forever.
+ <braunr> hardly
+ <braunr> for that, killall would have to run a long time
+ <quotemstr> braunr: No, I'm talking about our hypothetical killall itself
+ being killed after taking out a reference on another process, but before
+ releasing it
+ <braunr> but a malicious killall could
+ <braunr> when a task is destroyed, its capability space is destroyed too
+ <braunr> removing all the references it previously had
+ <quotemstr> Ah, I see.
+ <braunr> the leaks we have occur in servers
+ <braunr> which sometimes act as clients to other servers
+ <braunr> and run forever
+
+
+# Crashes due to rpctrace
+
+## IRC, freenode, #hurd, 2014-02-18
+
+ <braunr> something is wrong in the proc server
+ <braunr> rpctrace is often causing it to crash ..