[[!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 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 IRC, freenode, #hurd, 2011-07-22 hm, why /proc/$pid/stat is 600 instead of 644 of linux? pinotree, it reveals information which, while not that sensitive, would not be available to users through the normal proc interface. (it's available through the ps command which is setuid root) we discussed at some point making it 644, IIRC. hm, then why is it not a problem on eg linux? (btw you can change it with the -s option.) 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. IIRC it's not sensitive but you need the task port to query it. like, thread times or something. status is 644 though 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"]] # `/proc/[PID]/fd/` ## IRC, freenode, #hurd, 2012-04-24 braunr: /proc/*/fd can be implemented in several ways. none of them would require undue centralisation braunr: the easiest would be adding one more type of magic lookup to the existing magic lookup mechanism wait, I mean /proc/self... for /proc/*/fd it's even more straighforward -- we might even have a magic lookup for that already i guess the ideal thing would be implement that fd logic in libps 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 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 :-) youpi: How much info for /proc/*/fd is possible to get from libps? Re: d-h@ see my mail I don't think there is an interface for that processes handle fds themselves so libps would have to peek in there and I don't remember having seen any code like that 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 pinotree: For me that does not ring a bell on RPCs. Don't know what magic means,, for /proc/self/fd we have a magic lookup for /proc/pid/fd, I don't think we have magic lookup* magic lookup == RPC? magic lookup is a kind of answer to the lookup RPC that basically says "it's somewhere else, see there" the magic FD lookup tells the process "it's your FD number x" which works for /proc/self/fd, but not /proc/pid/fd youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that could be used `msgport' should have --get-fd, actually civodul: I assumed that the reason why msgport doesn't have it is that it didn't exist so we can get a port on the fd but then how to know what it is? youpi: ah, you mean for the /proc/X/fd symlinks? good question it's not designed to be mapped back to names, indeed :-) youpi: yeah, I realized myself that only /proc/self/fd is trivial BTW, in Linux it's nor real symlinks. it's magic, with some very strange (but useful in certain situations) semantics not real symlinks 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` ## IRC, OFTC, #debian-hurd, 2012-06-20 bdefreese: the two elfutils tests fail because there are no /proc/$pid/maps files that code is quite relying on linux features, like locating the linux kernel executables and their modules, etc (see eg libdwfl/linux-kernel-modules.c) refactor elfutils to have the linux parts executed only on linux :D Oh yeah, the maintainer already seems really thrilled about Hurd.. Did you see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041 ? kurt is generally helpful with us (= hurd) 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 # IRC, freenode, #hurd, 2011-06-19 jkoenig: procfs question: in process.c, process_lookup_pid, why is the entries[2].hook line repeated twice? pinotree, let me check pinotree, it's probably just a mistake, there's no way the second one has any effect jkoenig: i see, it looked like you c&p'd that code accidentally 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