IRC.

4 files changed, 386 insertions, 2 deletions

diff --git a/faq/how_many_developers/discussion.mdwn b/faq/how_many_developers/discussion.mdwn
index 9fc44f25..6ca47c9a 100644
--- a/faq/how_many_developers/discussion.mdwn
+++ b/faq/how_many_developers/discussion.mdwn
@@ -8,7 +8,48 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
 is included in the section entitled [[GNU Free Documentation
 License|/fdl]]."]]"""]]
 
-IRC, freenode, #hurd, 2011-07-09
+# IRC, freenode, #hurd, 2011-05-22
+
+    <silver_hook> Since apparently Hurd's aim is a very stable and transparent
+      system ...why aren't there any companies backing it up?
+    <antrik> silver_hook: it's not in a state yet where it would be
+      commercially interesting
+    <antrik> silver_hook: and after some epic failures in the 90s, few
+      companies dare to invest in microkernel development...
+    <silver_hook> Isn't MacOS X running on top of Mach?
+    <antrik> yes, but it's not a true microkernel system
+    <antrik> for one, it's single-server, which is boring
+    <antrik> also it uses co-location, i.e. runs all the system code in the
+      kernel address space -- they are separated only formally
+    <antrik> even NT is more of a microkernel system I think
+    <silver_hook> Oh, OK, I'm not that knowledgeable about kernels to know
+      that.
+    <antrik> well, now you know :-)
+    <silver_hook> Yup, thanks :)
+    <antrik> most people don't know this, so don't worry
+    <silver_hook> I was just wondering that it might be potentially an ideal
+      server system, right?
+    <antrik> well, *potentially* it might be an ideal general-purpose system,
+      which includes server use... though personally I think the advantages of
+      the architecture are more visible in desktop use, as servers tend to be
+      rather streamlined, with little need for individualisation :-)
+    <antrik> however, it still remains to be proven that true (multi-server)
+      microkernel operating systems actually work for general-purpose
+      applications...
+    <silver_hook> antrik: I mean regarding hosting or virtual servers.
+    <antrik> so far, they are only successful in the much simpler embedded
+      space
+    <antrik> well, yes, the Hurd architecture in theory allows very much
+      flexibility regarding virtual environments... I once blogged about
+      that. not sure whether server applications really require that
+      flexibility though. I think most people are pretty happy with the various
+      virtualisation/container solutions available in Linux. again, the
+      flexibility is more relevant in the desktop space IMHO
+    <antrik> dosn't mean it wouldn't be useful for servers too... just not as
+      much of a selling point I fear :-)
+
+
+# IRC, freenode, #hurd, 2011-07-09
 
     <antrik> gnu_srs1: regarding your question why people aren't interested in
       workin on Hurd: Eric Raymond explains it pretty well in his famous
diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index aa8b966a..33da7afd 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -72,6 +72,9 @@ available.
 
 Read about translator [[short-circuiting]].
 
+The [[concept|concepts]] of translators creates its own problems, too:
+[[open_issues/translators_set_up_by_untrusted_users]].
+
 
 # Existing Translators
 
diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn
index bf8ae70a..12a2699f 100644
--- a/open_issues/systemd.mdwn
+++ b/open_issues/systemd.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011 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
@@ -24,3 +24,69 @@ Introduction: [*Ressourcen-Verwaltung mit Control Groups (cgroups)*
 Daniel Gollub, Stefan Seyfried, 2010-10-14.
 
 Likely there's also some other porting needed.
+
+
+# IRC, OFTC, #debian-hurd, 2011-05-19
+
+    <pinotree> pochu: http://news.gmane.org/gmane.comp.gnome.desktop - the
+      "systemd as dependency" and all the messages in it don't give me a bright
+      future for gnome on hurd...
+    <pochu> yeah, I've read the thread
+    <pochu> it's only a proposal so far... hopefully it'll be rejected, or they
+      will only accept the interfaces that other OSes can implement...
+    <pochu> we'll see
+    <pinotree> you can always help me with kde on hurd, would be nice ;)
+    <pochu> hehe
+    <pinotree> pochu: well, even if the depenency is rejected, the whole «don't
+      give a damn about non-linux and only bless linux for the "gnome os"» is a
+      bit... worrying attitude
+    <pochu> yeah... it doesn't come from all the community though
+    <pochu> I'm sure some people have always thought that way
+    <tschwinge> Or we could get systemd going?  :-)
+    <pochu> good luck with that :p
+    <guillem> tschwinge: haha!? :)
+    <tschwinge> That bad?
+    <guillem> tschwinge: if you mean by that forking indefinitely then maybe
+    <guillem> tschwinge: upstream has expressely stated multiple times, no
+      interest whatsoever in any kind of portability to anything non-Linux
+    <guillem> or even older Linux versions!
+    <guillem> to the point of rejecting patches, because they "clutter" the
+      source code...
+    <tschwinge> Well, then let's ``just'' implement the Linux interfaces.  :-)
+    <guillem> tschwinge: then you'll be always playing catch up
+    <guillem> tschwinge: for example several of the Linux-only things upstream
+      makes heavy use of, are pretty recent Linux-only additions to the kernel,
+      but equivalents have been present on FreeBSD for years
+    <tschwinge> Yeah.  I'm half-serious, half-joking.
+    <tschwinge> I haven't looked at the systemd code at all.
+    <guillem>
+      https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html
+      for a list of its dependencies
+    <guillem> some are just glibc extensions though
+    <guillem> and some are IMO optional and should be conditionalized, but...
+    <guillem> pochu: I don't think that attitude is that old, there was a time
+      when Linux was not used widely, or even that functional, I think it has
+      been taking strength since the Linux Plumbers Cartel started :)
+    <guillem> as in one thing is not caring about anything non-Linux, the other
+      is outright rejecting portability fixes
+    <guillem> tschwinge: in any case, these "recent" events are "pissing me
+      off" to the point of having considered several times implementing
+      portable replacements for some of those Utopia projects, the problem as
+      always is time though :)
+    <guillem> tschwinge: and the issue is not only with systemd, upstart's
+      upstream has the same approach to portability, if you want to port it,
+      you'll have to maintain a fork
+    <pochu> let's create our own init system, make it better than anyone else,
+      and when people start switching to it, let's start using hurd-only APIs
+      :)
+    <tschwinge> We already had someone work on that.  Like ten years ago.  DMD.
+      Daemon Managing Daemons.  <http://directory.fsf.org/project/DMD/>
+    <guillem> the real problem with that attitude is not the lack of care for
+      portabilty, the real problem is that these people are pushing for their
+      stuff all over the stack, and most of the time deprecating their own
+      stuff after a while when they have rewritten it from scratch, leaving the
+      burden of maintaining the old stuff to the other ports
+    <guillem> witness HAL, ConsoleKit, etc etc
+    <guillem> (anyway enough ranting I guess :)
+    <tschwinge> Yeah, it's true, though.
+    <pochu> agreed
diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn
new file mode 100644
index 00000000..edc92796
--- /dev/null
+++ b/open_issues/translators_set_up_by_untrusted_users.mdwn
@@ -0,0 +1,274 @@
+[[!meta copyright="Copyright © 2011 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
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+
+# IRC, freenode, #hurd, 2011-07-17
+
+    <antrik> Reventlov: this is the so-called "firmlink issue" -- though AFAIK
+      it doesn't actually apply to firmlinks ;-)
+    <antrik> the problem is that any user can in theory create and set up a
+      special translator, which will redirect to another directory, without any
+      indication that it's a link
+    <braunr> but this doesn't supersede the file system permissions, does it ?
+    <antrik> as a result, if someone runs rm -r on the directory containing
+      that translator (which could be a world-writable one such as tmp), the rm
+      -r will descend into the directory, and thus remove it with the
+      permissions of the user who ran the rm -- not the one who set up the
+      translator
+    <braunr> oh i see, when tmp gets cleared by a script run as root, your home
+      is deleted ?
+    <antrik> right
+    <antrik> of course, the workaround is trivial: just don't follow
+      translators set up by untrusted users
+    <antrik> (which is precisely the default policy for FUSE BTW)
+    <braunr> which is the general policy around memory managers in general
+    <antrik> it's just nobody cared to implement this change
+    <youpi> antrik: does rm use O_NOTRANS ?
+    <antrik> youpi: I'm pretty sure it doesn't
+    <youpi> so it's still an issue for now
+    <antrik> yes, it's still an issue. it's just not a really fundamental
+      problem as macrus claimed it to be... [sigh]
+    <youpi> well, fix rm and then you can say it's not an issue any more
+    <braunr> does it only concern rm ?
+    <antrik> youpi: rm is just an example. the problem is much more generic: a
+      malicious translator can do all kinds of harm
+    <youpi> sure
+    <youpi> it's just about tools not blindly following things
+    <antrik> the only simple and effective answer is not to follow translators
+      from untrusted users by default
+    <youpi> antrik: but then /dev/null can't be non-root
+    <braunr> depends how "untrusted users" are identified
+    <antrik> we discussed a more sophisticated solution with cfhammer, that
+      would change the way reauthentication works in lookups, and should
+      prevent these kinds of permission escalation without preventing desirable
+      uses... but it still wouldn't address DOS issues, so it would be only a
+      partial solution
+    <antrik> youpi: why should it?
+    <manuel> (http://lists.gnu.org/archive/html/bug-hurd/2009-11/msg00231.html
+      for the most sophisticated solution)
+    <antrik> braunr: well, currently the permission system generally trusts
+      root and the own user. implementing something else might be tricky... not
+      sure
+    <antrik> manuel: yes, that's precisely the discussion I was referring
+      to... thanks for the link :-)
+    <youpi> antrik: depends what you mean by "follow"
+    <youpi> what DOS are you thinking of?
+    <antrik> youpi: a translator can generate endless amounts of "data"; a
+      translator can generate endless recursive directory tress; or it can just
+      never return from RPCs... all things that can do pretty much harm
+      depending on the situation
+    <antrik> filesystem clients generally trust filesystem operations to be
+      safe -- and that's just not true anymore with filesystems run by
+      untrusted users
+    <antrik> (be it Hurd translators or FUSE modules)
+    <antrik> this is a fundamental problem as marcus and neal rightly observed
+    <antrik> I just don't agree about the seriousness of the consequences
+    <antrik> I don't think not following untrusted translators really looses us
+      much
+    <youpi> EDOOMANYNEGATIONS
+    <youpi> s/D/T
+    <youpi> again, what do you mean by "following" ?
+    <youpi> always use O_NOTRANS ?
+    <tschwinge> Yes, I think.
+    <youpi> or never accept a REAUTH ?
+    <youpi> O_NOTRANS would mean ftpfs running as root, brrr
+    <youpi> it's not really true that clients always trust filesystem
+      operations
+    <youpi> the "not returning" case for instance, also appears with nfs mounts
+    <antrik> no, not always use O_NOTRANS. just be more selective about what
+      translators to follow. specifically, don't follow translators set up by
+      untrusted users. (unless explicitly requested)
+    <antrik> you can think of it as O_NO_UNTRUSTED_TRANS
+    <antrik> note that if you run ftpfs under a special user, who is not root
+      but trusted by root, this would still be fine. I hope it shouldn't be too
+      hard to implement that...
+    <antrik> as for NFS: clients generally do *not* try to catch possible
+      failures. if the NFS server doesn't return, the clients hang forever. but
+      the NFS server is generally trusted, so this is not much of a problem
+    <antrik> BTW, I guess not accepting reauth from untrusted translators would
+      also fix the privilege escalations (similar to the proposed modified
+      reauth mechanism, only more invasive); but it wouldn't fix the DoS issues
+    <ArneBab> antrik: would that also be an issue for a run translator, which
+      runs a command on read?
+    <ArneBab> youpi: couldn’t ftpfs have root drop priviledges?
+    <ArneBab> like a runas trans
+    <ArneBab> essertially su for translators to drop privs
+    <antrik> ArneBab: hm... if we can make sure that the translator was started
+      as root, and dropped privileges later, I guess that would be fine... not
+      sure how hard that is
+    <antrik> ArneBab: but I think it would be more elegant to start the
+      translators as trusted non-root users in the first place
+    <ArneBab> then i ph.avme to trust them
+    <ArneBab> deper hierarchy
+    <ArneBab> deeper
+    <ArneBab> but essertially the same
+    <ArneBab> if then someone mounted his home himself, would I be able to read
+      it?
+    <ArneBab> /home/user
+    <ArneBab> antrik: if not, that would be really non-nice
+    <antrik> ArneBab: sorry, but we simply *can't* trust a translator set up by
+      an untrusted user. if he controls it, he can make it behave maliciously
+    <antrik> we could in theory try to come up with a proxy that catches
+      problematic semantics, and presents a "safe" variant to the actual
+      clients... but that would be not-trivial, and I'm not sure how safe it
+      can be made
+    <antrik> ArneBab: of course you should always have the option to explicitly
+      say that you want to trust the translator, if you think the user doesn't
+      have malicious intentions :-)
+    <antrik> (I think nsmux would be a good way to achieve this...)
+    <braunr> unless it's really really necessary (and i don't see why it would
+      be), no design should force a process to start with privileges and drop
+      them
+    <braunr> having a set of trusted users (e.g. uid < 100) is a nice solution
+      to the problem imho
+    <braunr> or part of a group, 100 is a non-hurdish static limit
+    <ArneBab> What user is running a passive translator?
+    <braunr> passive translators are a pain for such things :/
+    <braunr> a command line and attach point are not enough to persistently
+      encode the execution context of the tranlator
+    <ArneBab> What user is running a passive translator?
+    <ArneBab> sorry
+    <braunr> the one owning the inode if i'm right
+    <ArneBab> so actually the orly problem are recursive commands, which also
+      are a problem with plain symlinks?
+    <braunr> i'm not sure
+    <ArneBab> Is thene any havoc a translator can wreak that a symlink can’t?
+    <braunr> well, as symlinks are translators, if a translator can damage
+      something, a symlink may too
+    <ArneBab> but not in Linux?
+    <braunr> err
+    <braunr> there are no translator in linux
+    <ArneBab> → commands could just treat translators as symlinks
+    <ArneBab> jepp, but it has symlinks
+    <braunr> no, this would defeat the purpose of translators :p
+    <braunr> and it's just no doable
+    <braunr> you would have recursion everywhere
+    <ArneBab> why?
+    <braunr> because every file access is sent to a translator
+    <ArneBab> hm, yes
+    <braunr> and we don't want to change commands
+    <braunr> we want to fix the design
+    <ArneBab> → only untrusted trans 
+    <braunr> rather than considering them as symlinks, just consider them as
+      untrusted translators
+    <braunr> this doesn't change the semantics, only the action of accessing a
+      node or not
+    <braunr> but as antrik said, this has to be done :)
+    <braunr> the real problem would simplify to "how do you know if a
+      translator can be trusted", which is a matter of selecting the righ
+      identification strategy
+    <braunr> one strong strategy would be to have a port right copied to each
+      trusted task
+    <braunr> i wonder if one of the special ports could be used for that
+    <braunr> or if we have to add a new one
+    <ArneBab> so when I login, I would give port rights to trusted uids?
+    <braunr> no
+    <braunr> when a trusted translator starts a passive translator attached on
+      a node owned by root, it would copy its trusted right to the new task
+    <braunr> much like the device master port is passed to root tasks
+    <braunr> but i'm not sure this mechanism can be safely used to know if the
+      translator can be trusted
+    <braunr> the translator would be able to actively call services requiring
+      this capability
+    <braunr> but i guess client tasks would have to ask for the translator to
+      prove it's trusted
+    <braunr> which is a problem because the issue is to know if it can be
+      trusted before asking it anything
+    <braunr> another way is to register trusted tasks in another server, and
+      ask this server if the target translator is trusted
+    <braunr> i"m pretty sure these strategies already exist in some form on the
+      hurd
+    <ArneBab> hm
+    <braunr> does someone here have an idea why BSD-derived VMs account wiring
+      information at the high level vm_map instead of storing it in lower level
+      vm_page ?
+    <ArneBab> braunr: a translator anywhene in the FS can only be there, if the
+      creator had sufficient rights to the node, right?
+    <ArneBab> so wouldn’t it suffice to check the access rights?
+    <braunr> no
+    <braunr> ismple example: /dev/null is owned by root, but you have read
+      access to it
+    <braunr> hm that may not answer your question actually
+    <braunr> what access right would you check ?
+    <braunr> if someone creates a node with rights 777, do you still want to
+      access it ?
+    <ArneBab> no
+    <braunr> simple enough i hope :)
+    <ArneBab> arg…
+    <ArneBab> if I can write to it, I can give it a translaton
+    <ArneBab> translator
+    <braunr> but this doesn't tell you it can be trusted
+    <ArneBab> well, actually: yes, access, but not recurse
+    <braunr> the owner sets his own rights, and you can't trust the owner
+    <braunr> unless it's root, but you don't want all your translators to run
+      as root
+    <ArneBab> it can act as its owner?
+    <ArneBab> yes
+    <braunr> well, as i told you, a passive translator is started by its parent
+      translator (the one managing the file systeme node it's attached to)
+    <braunr> the new translator runs as the user owning the node
+    <braunr> (if i'm right)
+    <ArneBab> …and so on, till noot starts the first
+    <ArneBab> root
+    <braunr> ?
+    <ArneBab> root starts /, right?
+    <braunr> no
+    <braunr> gnumach starts /
+    <ArneBab> ah, right
+    <braunr> gnumach starts somefs.static
+    <braunr> which attaches at /
+    <braunr> and runs with root privileges
+    <braunr> keep in mind that unix permissions are implemented as capabilities
+      on the hurd
+    <ArneBab> → root has it / it’s root
+    <braunr> the rights you have aren't limited to those permissions
+    <ArneBab> jepp
+    <braunr> and it's not "until"
+    <ArneBab> so why should I not access a translator run by someone else? I
+      just don’t want to do any active command (recurse)… hm… can a translator
+      turn a read request into a write?
+    <braunr> that's the only problem
+    <ArneBab> program with my rights wants to read, but the translator makes it
+      write instead?
+    <braunr> no
+    <braunr> a translator can do pretty much anything with your request
+    <ArneBab> with my rights?
+    <braunr> no
+    <braunr> the most obvious example of DoS is simply not answering
+    <braunr> your process hangs
+    <braunr> considering some file system accesses, a translator could return
+      inconsistent data
+    <ArneBab> so if the translator tries to make me write instead of read, it
+      can do so only when the owner of the translaton can write to the file in
+      question?
+    <braunr> a well written application shouldn't have too much trouble dealing
+      with it but some aren't that well written
+    <braunr> this has *nothing* to do with read/write permissions
+    <braunr> you should read the critique :p
+
+[[hurd/critique]]
+
+    <ArneBab> ln -s /home/you /home/me → “why don’t you look into my home?”
+    <ArneBab> read it again, that is :)
+    <ArneBab> (has been some time since I read it)
+    <antrik> braunr: you just described the auth mechanism ;-)
+    <antrik> ArneBab: symlinks can do considerably less than translators; and
+      even these caused a lot of trouble when introduced (and still cause
+      sometimes)
+    <antrik> we can't make every application aware of translators
+    <antrik> indeed I believe we can a avoid many problems by presenting
+      various translators as symlinks -- but this is not approriate for all
+      translators
+    <antrik> it is something the translator itself decides, so it's not helpful
+      to solve security issues at all
+    <antrik> and as braunr already pointed out, this wouldn't help with DoS
+      problems