diff options
Diffstat (limited to 'hurd/translator/procfs/jkoenig')
| -rw-r--r-- | hurd/translator/procfs/jkoenig/discussion.mdwn | 341 |
1 files changed, 341 insertions, 0 deletions
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn new file mode 100644 index 00000000..cca9c3f3 --- /dev/null +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -0,0 +1,341 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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 + + <youpi> jkoenig: is it not possible to provide a /proc/self which points at + the client's pid? + <pinotree> (also, shouldn't /proc/version say something else than "Linux"?) + <youpi> to make linux tools work, no :/ + <youpi> kfreebsd does that too + <pinotree> really? + <youpi> yes + <youpi> (kfreebsd, not freebsd) + <pinotree> does kbsd's one print just "Linux version x.y.z" too, or + something more eg in a second line? + <pinotree> (as curiosity) + <youpi> % cat /proc/version + <youpi> Linux version 2.6.16 (des@freebsd.org) (gcc version 4.3.5) #4 Sun + Dec 18 04:30:00 CET 1977 + <pinotree> k + <giselher> I had some problems with killall5 to read the pid from /proc, Is + this now more reliable? + <youpi> I haven't tested with jkoenig's implementation + [...] + <pinotree> looks like he did 'self' too, see rootdir_entries[] in rootdir.c + <youpi> but it doesn't point at self + <antrik> youpi: there is no way to provide /proc/self, because the server + doesn't know the identity of the client + <youpi> :/ + <antrik> youpi: using the existing mechanisms, we would need another magic + lookup type + <antrik> 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 + <antrik> 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 :-) + <youpi> but we've seen how much that'd help with a lot of other stuff + <antrik> I'm not sure whether we discussed this on the ML at some point, or + only on IRC + <youpi> it "just" needs to be commited :) + <antrik> in either case, it can't hurt to bring this up again :-) + + +# root group + +IRC, #hurd, around October 2010 + + <pinotree> 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 + + <pochu> is there a reason for /proc/$pid/stat to be 400 and not 444 like on + Linux? + <pochu> there is an option to procfs to make it 444 like Linux + <pochu> jkoenig: ^ + <jkoenig> pochu, hi + <jkoenig> /proc/$pid/stat reveals information which is not usually + available on Hurd + <jkoenig> so I made it 400 by default to avoid leaking anything + <pochu> is there a security risk in providing that info? + <jkoenig> probably not so much, but it seemed like it's not really a + descision procfs should make + <jkoenig> I'm not sure which information we're speaking about, though, I + just remember the abstract reason. + <pochu> things like the pid, the memory, the priority, the state... + <pochu> sounds safe to expose + <jkoenig> also it's 0444 by default in "compatible" mode + <jkoenig> (which is necessary for the linux tools to work well) + <pochu> yeah I saw that :) + <pochu> 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 + <pochu> we're already 'leaking' part of that info through e.g. ps + <jkoenig> I think /proc should be translated by /hurd/procfs --compatible + by default (I'm not sure whether it's already the case) + <jkoenig> 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. + <pochu> jkoenig: it's not, at least not on Debian + <pochu> youpi: hi, what do you think about starting procfs with + --compatible by default? + <pochu> youpi: or changing /proc/$pid/stat to 0444 like on Linux + (--compatible does that among a few other things) + <youpi> I guess you need it for something? + <pochu> I'm porting libgtop :) + <youpi> k + <pochu> though I still think we should do this in procfs itself + <youpi> ymmv + <jkoenig> pochu, youpi, --compatible is also needed because mach's high + reported sysconf(_SC_CLK_TCK) makes some integers overflow (IIRC) + <youpi> agreed + <jkoenig> luckily, tools which use procfs usually try to detect the value + /proc uses rather than rely on CLK_TCK + <jkoenig> (so we can choose whatever reasonable value we want) + +IRC, freenode, #hurd, 2011-03-28 + + <antrik> jkoenig: does procfs expose any information that is not available + to everyone through the proc server?... + <antrik> also, why is --compatible not the default; or rather, why is there + even another mode? the whole point of procfs is compatibility... + <jkoenig> antrik, yes, through the <pid>/environ and (as mentionned above) + <pid>/stat files, but I've been careful to make these files readable only + to the process owner + <jkoenig> --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 + <antrik> what specification? + <jkoenig> the linux proc(5) manpage + <jkoenig> which says clock tick counters are in units of + 1/sysconf(_SC_CLK_TCK) + <antrik> so you are saying that there is some information that the Hurd + proc server doesn't expose to unprivileged processes, but linux /proc + does? + <jkoenig> yes + <antrik> that's odd. I wonder what the reasoning behind that could be + <antrik> but this information is available through Hurd ps? + <antrik> BTW, what exactly is _SC_CLK_TCK supposed to be? + <pinotree> jkoenig: hm, just tried with two random processes on linux + (2.6.32), and enrivon is 400 + <pinotree> (which makes sense, as you could have sensible informations eg + in http_proxy or other envvars) + <jkoenig> antrik, CLK_TCK is similar to HZ (maybe clock resolution instead + of time slices ?) + <jkoenig> sysconf(3) says "The number of clock ticks per second." + <jkoenig> antrik, I don't remember precisely what information this was, but + ps-hurd is setuid root. + <jkoenig> 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. + <antrik> but Linux /proc acutally uses HZ as the unit IIRC? or is + _SC_CLK_TCK=HZ on Linux?... + <jkoenig> I expect they're equal. + <jkoenig> in practice procps uses heuristics to guess what value /proc uses + (for compatibility purposes with older kernels) + <jkoenig> I don't think HZ is POSIX, while _SC_CLK_TCK is specifies as the + unit for (at least) the values returned by times() + <jkoenig> s/specifies/specified/ + <jkoenig> 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. + <antrik> well, as long as the information is exposed through ps, there is + no point in hiding it in procfs... + <antrik> and I'm aware of the crazy guessing in libproc... I was actually + mentoring the previous procfs implementation + <antrik> (though I never got around to look at his buggy code...) + <jkoenig> ok + +IRC, freenode, #hurd, 2011-07-22 + + <pinotree> hm, why /proc/$pid/stat is 600 instead of 644 of linux? + <jkoenig> pinotree, it reveals information which, while not that sensitive, + would not be available to users through the normal proc interface. + <jkoenig> (it's available through the ps command which is setuid root) + <jkoenig> we discussed at some point making it 644, IIRC. + <pinotree> hm, then why is it not a problem on eg linux? + <jkoenig> (btw you can change it with the -s option.) + <jkoenig> pinotree, it's not a problem because the information is not that + sensitive, but when rewriting procfs I preferred to play it self and + consider it's not procfs' job to decide what is sensitive or not. + <jkoenig> IIRC it's not sensitive but you need the task port to query it. + <jkoenig> like, thread times or something. + <pinotree> status is 644 though + <jkoenig> but status contains information which anyone can ask to the proc + server anyway, I think. + + +# `/proc/mounts`, `/proc/[PID]/mounts` + +IRC, freenode, #hurd, 2011-07-25 + + < pinotree> jkoenig: btw, what do you think about providing empty + /proc/mounts and /proc/$pid/mounts files? + < jkoenig> pinotree, I guess one would have to evaluate the consequences + wrt. existing use cases (in other words, "I have absolutely no clue + whatsoever about whether that would be desirable" :-) + < jkoenig> pinotree, the thing is, an error message like "/proc/mounts: No + such file or directory" is rather explicit, whereas errors which would be + caused by missing data in /proc/mounts would maybe be harder to track + < braunr> this seems reasonable though + < braunr> there already are many servers with e.g. grsecurity or chrooted + environments where mounts is empty + < pinotree> well, currently we also have an empty mtab + < braunr> pinotree: but what do you need that for ? + < braunr> pinotree: the init system ? + < pinotree> and the mnt C api already returns no entries (or it bails out, + i don't remember) + < pinotree> not a strict need + + +# `/proc/[PID]/auxv`, `/proc/[PID]/exe`, `/proc/[PID]/mem` + +Needed by glibc's `pldd` tool (commit +11988f8f9656042c3dfd9002ac85dff33173b9bd). + + +# `/proc/self/exe` + +[[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]]. Needed by glibc's +`stdlib/tst-secure-getenv.c`. + + +# `/proc/[PID]/fd/` + +## IRC, freenode, #hurd, 2012-04-24 + + <antrik> braunr: /proc/*/fd can be implemented in several ways. none of + them would require undue centralisation + <antrik> braunr: the easiest would be adding one more type of magic lookup + to the existing magic lookup mechanism + <antrik> wait, I mean /proc/self... for /proc/*/fd it's even more + straighforward -- we might even have a magic lookup for that already + <pinotree> i guess the ideal thing would be implement that fd logic in + libps + <antrik> pinotree: nope. it doesn't need to ask proc (or any other server) + at all. it's local information. that's what we have the magic lookups for + <antrik> one option we were considering at some point would be using the + object migration mechanism, so the actual handling would still happen + client-side, but the server could supply the code doing it. this would + allow servers to add arbitrary magic lookup methods without any global + modifications... but has other downsides :-) + <gnu_srs> youpi: How much info for /proc/*/fd is possible to get from + libps? Re: d-h@ + <youpi> see my mail + <youpi> I don't think there is an interface for that + <youpi> processes handle fds themselves + <youpi> so libps would have to peek in there + <youpi> and I don't remember having seen any code like that + <gnu_srs> 10:17:17< antrik> wait, I mean /proc/self... for /proc/*/fd it's + even more straighforward -- we might even have a magic lookup for that + already + <gnu_srs> pinotree: For me that does not ring a bell on RPCs. Don't know + what magic means,, + <youpi> for /proc/self/fd we have a magic lookup + <youpi> for /proc/pid/fd, I don't think we have + <gnu_srs> magic lookup* + <gnu_srs> magic lookup == RPC? + <youpi> magic lookup is a kind of answer to the lookup RPC + <youpi> that basically says "it's somewhere else, see there" + <youpi> the magic FD lookup tells the process "it's your FD number x" + <youpi> which works for /proc/self/fd, but not /proc/pid/fd + <civodul> youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that + could be used + <civodul> `msgport' should have --get-fd, actually + <youpi> civodul: I assumed that the reason why msgport doesn't have it is + that it didn't exist + <youpi> so we can get a port on the fd + <youpi> but then how to know what it is? + <civodul> youpi: ah, you mean for the /proc/X/fd symlinks? + <civodul> good question + <civodul> it's not designed to be mapped back to names, indeed :-) + <antrik> youpi: yeah, I realized myself that only /proc/self/fd is trivial + <antrik> BTW, in Linux it's nor real symlinks. it's magic, with some very + strange (but useful in certain situations) semantics + <antrik> not real symlinks + <antrik> it's very weird for example for fd connected to files that have + been unlinked. it looks like a broken symlink, but when dereferencing + (e.g. with cp), you get the actual file contents... + + +# `/proc/[PID]/maps` + +[[!tag GNU_Savannah_bug 32770]] + + +## IRC, OFTC, #debian-hurd, 2012-06-20 + + <pinotree> bdefreese: the two elfutils tests fail because there are no + /proc/$pid/maps files + <pinotree> that code is quite relying on linux features, like locating the + linux kernel executables and their modules, etc + <pinotree> (see eg libdwfl/linux-kernel-modules.c) + <pinotree> refactor elfutils to have the linux parts executed only on linux + :D + <bdefreese> Oh yeah, the maintainer already seems really thrilled about + Hurd.. Did you see + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041 ? + <pinotree> kurt is generally helpful with us (= hurd) + <pinotree> most probably there he is complaining that we let elfutils build + with nocheck (ie skipping the test suite run) instead of investigate and + report why the test suite failed + +[[!GNU_Savannah_bug 32770]] + + +# IRC, freenode, #hurd, 2011-06-19 + + <pinotree> jkoenig: procfs question: in process.c, process_lookup_pid, why + is the entries[2].hook line repeated twice? + <jkoenig> pinotree, let me check + <jkoenig> pinotree, it's probably just a mistake, there's no way the second + one has any effect + <pinotree> jkoenig: i see, it looked like you c&p'd that code accidentally + <jkoenig> pinotree, it's probably what happened, yes. + + +# `/proc/[PID]/cwd` + +## IRC, freenode, #hurd, 2012-06-30 + + * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying + on "internal" (but exported) glibc functions + + +# "Unusual" PIDs + +Not actually related to procfs, but here seems to be a convenient place for +filing these: + + +## IRC, freenode, #hurd, 2012-08-10 + + <braunr> too bad the proc server has pid 0 + <braunr> top & co won't show it + + +## IRC, OFTC, #debian-hurd, 2012-09-18 + + <pinotree> youpi: did you see + https://enc.com.au/2012/09/careful-with-pids/' + <pinotree> ? + <youpi> nope |