Re: learning curve
Hi, On Thu, Nov 19, 2009 at 08:16:32PM +0100, Michael Banck wrote: > I said it before, and I'll say it again now: the Hurd does not need > more users, it does not even need a lot more developers, it just need > a few *really smart* developers. Perhaps you should attend a presentation on community management. I have attended a few. In *every* community project, you get a similar distribution of people: about 90% who mostly just lurk; 10% that contribute in some ways; and among these, just a handful of core developers. Part of community management is encouraging people to move from the 90% to the 10%, and from the 10% to the handful -- but an equally important part is to increase the pool in the first place. You can't get and keep core developers, without making the project more interesting and welcoming in general. I agree that the learning curve discussion is not likely to help with this. (Unless perhaps if it's applied to something actually concerning the Hurd.) OTOH, I don't understand why you are so upset about it? It's not the kind of discussion likely to distract core developers from useful work... (BTW, I don't actually agree on the "really smart developers only" part either. Unless you are among those who believe that any work on the existing implementation is pointless, and only working on a new microkernel would provide any benefit...) > [...] or the merits of light or dark backgrounds in CSS. We didn't really discuss the merits of light and dark backgrounds. We were discussing whether setting a text color always demands setting a background color. This is not relevant to the Hurd itself, but certainly relevant to the Hurd website. If you don't like the idea of having a single list for the website and for Hurd development, why didn't you voice your objections when it was proposed?... -antrik-
Re: [PATCH 2/3] Implement mountee startup.
Hi, On Thu, Nov 19, 2009 at 10:28:37AM +0200, Sergiu Ivanov wrote: > + /* Fetch the effective UIDs of the unionfs process. */ > + nuids = geteuids (0, 0); > + if (nuids < 0) > +return EPERM; > + uids = alloca (nuids * sizeof (uid_t)); > + > + nuids = geteuids (nuids, uids); > + assert (nuids > 0); Hrmph, I didn't spot this before: I don't think the assert() is right -- "nuids" (or "ngids") being exactly 0, is probably a perfectly valid case... And even if it is not, the test in the assert should be equivalent to the EPERM test above, to avoid confusion. > + /* The mountee will be sitting on this node. This node is based on > + the netnode of the root node (it is essentially a clone of the > + root node), so that unionfs appears as the underlying translator > + to the mountee. Note the we cannot set the mountee on the root > + node directly, because in this case the mountee's filesystem will > + obscure the filesystem published by unionfs. */ Grammar nitpick: it should be "*would* obscure" :-) (It don't think it hampers understanding though, so I can't say that I really care... Just a hint for you :-) ) -antrik-
Re: [PATCH] Implement the sync libnetfs stubs.
Hi, On Thu, Nov 19, 2009 at 11:18:45AM +0200, Sergiu Ivanov wrote: > [...] Thus, if I did everything correctly, it seems that we have no > problems syncing really read-only filesystems either. Great :-) That's what I hoped for, just wanted to be sure. > +assert (err == 0); Another thing you forgot to change in the second loop... -antrik-
Re: Solving the firmlink problem with io_restrict_auth
Hi, On Thu, Nov 19, 2009 at 02:58:07PM +0100, Carl Fredrik Hammar wrote: > On Tue, Nov 17, 2009 at 08:55:38PM +0100, olafbuddenha...@gmx.net > wrote: > > It is actually a problem that this policy is not followed whenever > > an intermediate translator hands out a "real" port to another > > translator, and the client reauthenticates it. (The so-called > > "firmlink problem".) > > Having a ``proxy'' do an io_restrict_auth before passing on a port has > actually far reaching consequences. Remember that firmlink is only an > odd use of the regular hand-off protocol when going from one > translator to another, so using this policy throughout the Hurd would > mean we go from a peer-to-peer authority scheme to a very hierachical > one, where each step from one translator to another can only mean less > authority for the client. Yeah, so the question is: is this a bad thing? With the current scheme, the only way to make translators safe is to never follow translators set up by untrusted users. (Which BTW is also the policy used by FUSE by default.) Would changing the authentication scheme preclude any desirable (safe) use cases that are possible presently? > Note also that the fact that servers return an already authenticated > but restricted port that would solve the firmlink problem, rather the > client must refuse to reauthenticate ports on the server's request, > otherwise a malicious server could still trick the client. Yes, that was exactly my point. IMHO this should be changed -- though I'm not sure how exactly... > Also to do this properly we need to improve io_restrict_auth so it > restricts the allowed operations to the intersection of the allowed > operations of two sets of credentials, and not just to the operations > allowed of the intersection of two sets of credentials. I'm not yet convinced that this is really much of a problem in practice :-) -antrik-
Re: learning curve
olafbuddenha...@gmx.net, le Sun 22 Nov 2009 22:04:22 +0100, a écrit : > (BTW, I don't actually agree on the "really smart developers only" part > either. Unless you are among those who believe that any work on the > existing implementation is pointless, and only working on a new > microkernel would provide any benefit...) The existing implementation needs really smart developers. It needs not so smart developers too, but a lot of things that _need_ to be fixed (e.g. including parts of perl testsuite failures, ghc6 failures, I/O performance) probably won't be fixable without good skills. > > [...] or the merits of light or dark backgrounds in CSS. > > We didn't really discuss the merits of light and dark backgrounds. >[etc.] Well, at least the subject has let me drop the complete thread easily. Samuel
Re: [PATCH 2/3] Implement mountee startup.
Hi,
On Sun, Nov 22, 2009 at 09:05:16PM +0100, olafbuddenha...@gmx.net wrote:
> On Thu, Nov 19, 2009 at 10:28:37AM +0200, Sergiu Ivanov wrote:
>
> > + /* Fetch the effective UIDs of the unionfs process. */
> > + nuids = geteuids (0, 0);
> > + if (nuids < 0)
> > +return EPERM;
> > + uids = alloca (nuids * sizeof (uid_t));
> > +
> > + nuids = geteuids (nuids, uids);
> > + assert (nuids > 0);
>
> Hrmph, I didn't spot this before: I don't think the assert() is right --
> "nuids" (or "ngids") being exactly 0, is probably a perfectly valid
> case... And even if it is not, the test in the assert should be
> equivalent to the EPERM test above, to avoid confusion.
geteuids() actual error (in errno) should be returned instead of EPERM.
Also credentials can be changed at any moment by other processes through
the msg_set_init_port() RPC (very much like a signal), which becomes
a problem if the number of UIDs grows between the calls to geteuid().
So it would be more proper with a loop, e.g.:
nuids = geteuids (0, 0);
do {
old_nuids = nuids;
uids = alloca (nuids * sizeof (uid_t));
nuids = geteuids (nuids, uids);
} while (old_nuids < nuids);
But alloca() should be replaced with realloc() and cleanup code for the
memory should be added.
Actually, I don't see how any use of geteuids() won't run into this
problem. It would be much easier if it just returned malloced memory
to begin with...
Regards,
Fredrik
