From 1049f72d37aa1efc434c96eff42ad522eb331c90 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 28 Mar 2011 10:12:21 +0200 Subject: hurd/translator/procfs/jkoenig/discussion: Place for jkoenig procfs discussion. Also add recent IRC discussion. --- hurd/translator/procfs/jkoenig/discussion.mdwn | 168 +++++++++++++++++++++++++ 1 file changed, 168 insertions(+) create mode 100644 hurd/translator/procfs/jkoenig/discussion.mdwn (limited to 'hurd/translator/procfs/jkoenig') diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn new file mode 100644 index 00000000..b66af7de --- /dev/null +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -0,0 +1,168 @@ +[[!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 +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]] + +[[!toc]] + + +# Miscellaneous + +IRC, #hurd, around September 2010 + + jkoenig: from a quick read, your procfs implementation seems quite + simple, probably much more what I was expecting from Madhusudan (who + probably now hates you :) ) + jkoenig: is it not possible to provide a /proc/self which points at + the client's pid? + (also, shouldn't /proc/version say something else than "Linux"?) + to make linux tools work, no :/ + kfreebsd does that too + really? + yes + (kfreebsd, not freebsd) + does kbsd's one print just "Linux version x.y.z" too, or + something more eg in a second line? + (as curiosity) + % cat /proc/version + Linux version 2.6.16 (des@freebsd.org) (gcc version 4.3.5) #4 Sun + Dec 18 04:30:00 CET 1977 + k + I had some problems with killall5 to read the pid from /proc, Is + this now more reliable? + I haven't tested with jkoenig's implementation + [...] + looks like he did 'self' too, see rootdir_entries[] in rootdir.c + but it doesn't point at self + youpi: there is no way to provide /proc/self, because the server + doesn't know the identity of the client + :/ + youpi: using the existing mechanisms, we would need another magic + lookup type + an alternative idea I discussed with cfhammer once would be for + the client to voluntarily provide it's identity to the server... but that + would be a rather fundamental change that requires careful consideration + also, object migration could be used, so the implementation would + be provided by the server, but the execution would happen in the + client... but that's even more involved :-) + but we've seen how much that'd help with a lot of other stuff + I'm not sure whether we discussed this on the ML at some point, or + only on IRC + it "just" needs to be commited :) + in either case, it can't hurt to bring this up again :-) + + +# root group + +IRC, #hurd, around October 2010 + + the only glitch is that files/dirs have the right user as + owner, but always with root group + + +# `/proc/$pid/stat` being 400 and not 444, and some more + +IRC, freenode, #hurd, 2011-03-27 + + is there a reason for /proc/$pid/stat to be 400 and not 444 like on + Linux? + there is an option to procfs to make it 444 like Linux + jkoenig: ^ + pochu, hi + /proc/$pid/stat reveals information which is not usually + available on Hurd + so I made it 400 by default to avoid leaking anything + is there a security risk in providing that info? + probably not so much, but it seemed like it's not really a + descision procfs should make + I'm not sure which information we're speaking about, though, I + just remember the abstract reason. + things like the pid, the memory, the priority, the state... + sounds safe to expose + also it's 0444 by default in "compatible" mode + (which is necessary for the linux tools to work well) + yeah I saw that :) + my question is, should we change it to 0444 by default? if there + are no security risks and this improves compatibility, sounds like a good + thing to me + we're already 'leaking' part of that info through e.g. ps + I think /proc should be translated by /hurd/procfs --compatible + by default (I'm not sure whether it's already the case) + also I'm not sure why hurd-ps is setuid root, rather than the + proc server being less paranoid, but maybe I'm missing something. + jkoenig: it's not, at least not on Debian + youpi: hi, what do you think about starting procfs with + --compatible by default? + youpi: or changing /proc/$pid/stat to 0444 like on Linux + (--compatible does that among a few other things) + I guess you need it for something? + I'm porting libgtop :) + k + though I still think we should do this in procfs itself + ymmv + pochu, youpi, --compatible is also needed because mach's high + reported sysconf(_SC_CLK_TCK) makes some integers overflow (IIRC) + agreed + luckily, tools which use procfs usually try to detect the value + /proc uses rather than rely on CLK_TCK + (so we can choose whatever reasonable value we want) + +IRC, freenode, #hurd, 2011-03-28 + + jkoenig: does procfs expose any information that is not available + to everyone through the proc server?... + also, why is --compatible not the default; or rather, why is there + even another mode? the whole point of procfs is compatibility... + antrik, yes, through the /environ and (as mentionned above) + /stat files, but I've been careful to make these files readable only + to the process owner + --compatible is not the default because it relaxes this paranoia + wrt. the stat file, and does not conform to the specification with regard + to clock tick counters + what specification? + the linux proc(5) manpage + which says clock tick counters are in units of + 1/sysconf(_SC_CLK_TCK) + so you are saying that there is some information that the Hurd + proc server doesn't expose to unprivileged processes, but linux /proc + does? + yes + that's odd. I wonder what the reasoning behind that could be + but this information is available through Hurd ps? + BTW, what exactly is _SC_CLK_TCK supposed to be? + jkoenig: hm, just tried with two random processes on linux + (2.6.32), and enrivon is 400 + (which makes sense, as you could have sensible informations eg + in http_proxy or other envvars) + antrik, CLK_TCK is similar to HZ (maybe clock resolution instead + of time slices ?) + sysconf(3) says "The number of clock ticks per second." + antrik, I don't remember precisely what information this was, but + ps-hurd is setuid root. + anyway, if you run procfs --compatible as a user and try to read + foo/1/stat, the result is an I/O error, which is the result of the proc + server denying access. + but Linux /proc acutally uses HZ as the unit IIRC? or is + _SC_CLK_TCK=HZ on Linux?... + I expect they're equal. + in practice procps uses heuristics to guess what value /proc uses + (for compatibility purposes with older kernels) + I don't think HZ is POSIX, while _SC_CLK_TCK is specifies as the + unit for (at least) the values returned by times() + s/specifies/specified/ + antrik, some the information is fetched directly from mach by + libps, and understandably, the proc server does not give the task port to + anyone who asks. + well, as long as the information is exposed through ps, there is + no point in hiding it in procfs... + and I'm aware of the crazy guessing in libproc... I was actually + mentoring the previous procfs implementation + (though I never got around to look at his buggy code...) + ok -- cgit v1.2.3