* RFNOMNT @ 2009-01-04 7:08 Russ Cox 2009-01-04 12:21 ` [9fans] RFNOMNT lucio ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: Russ Cox @ 2009-01-04 7:08 UTC (permalink / raw) To: 9fans RFNOMNT, like everything in Plan 9, was put in because someone needed to use it, not as a purely academic exercise in adding features. It's behavior is what it is because that was necessary to get the job done. All the pie-in-the-sky "gee it would be nice if it worked like this, not that I'm actually using it" talk is unproductive. The "let's submit a patch and fix it" talk is scary. Russ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT 2009-01-04 7:08 RFNOMNT Russ Cox @ 2009-01-04 12:21 ` lucio 2009-01-04 17:04 ` Russ Cox 2009-01-04 16:12 ` erik quanstrom ` (2 subsequent siblings) 3 siblings, 1 reply; 16+ messages in thread From: lucio @ 2009-01-04 12:21 UTC (permalink / raw) To: 9fans > It's behavior is what it is > because that was necessary to get the job done. This approach can lead to unexpected side effects. Roman (or was it Nathaniel?) shows how RFNOMNT may be misunderstood to perform two functions when in fact there is only one purpose to it. In addition, only the original requestor and implementor are likely to know of the exceptions whereas anyone who might want to use it may overlook this and find herself on thin ice. With all due respect to those who conceived and coded the function, I think it is unfair to expect no criticism. Without a rationale, one is inevitably tempted to ask whether or not a better solution could be applied. And a rationale is no guarantee against criticism either. ++L ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT 2009-01-04 12:21 ` [9fans] RFNOMNT lucio @ 2009-01-04 17:04 ` Russ Cox 2009-01-04 18:27 ` lucio 0 siblings, 1 reply; 16+ messages in thread From: Russ Cox @ 2009-01-04 17:04 UTC (permalink / raw) To: lucio, Fans of the OS Plan 9 from Bell Labs I agree that it would be nice if the exceptions were documented in the man page. They are quite nicely documented in the code, though: /* * noattach is sandboxing. * * the OK exceptions are: * | it only gives access to pipes you create * d this process's file descriptors * e this process's environment * the iffy exceptions are: * c time and pid, but also cons and consctl * p control of your own processes (and unfortunately * any others left unprotected) */ n = chartorune(&r, up->genbuf+1)+1; /* actually / is caught by parsing earlier */ if(utfrune("M", r)) error(Enoattach); if(up->pgrp->noattach && utfrune("|decp", r)==nil) error(Enoattach); Russ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT 2009-01-04 17:04 ` Russ Cox @ 2009-01-04 18:27 ` lucio 0 siblings, 0 replies; 16+ messages in thread From: lucio @ 2009-01-04 18:27 UTC (permalink / raw) To: 9fans > I agree that it would be nice if the exceptions were > documented in the man page. They are quite nicely > documented in the code, though: That's easy enough to do, I'm sure. I'll look into that and see if I can build the confidence for a patch to, I presume, rfork(2)? The rationale is also at least to a large extent in the quoted comments, congratulations to the implementor. Is there a nice practical example one can use in the man page too? That would be very helpful in understanding the value and possibly the limitations of RFNOMNT. ++L ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT 2009-01-04 7:08 RFNOMNT Russ Cox 2009-01-04 12:21 ` [9fans] RFNOMNT lucio @ 2009-01-04 16:12 ` erik quanstrom 2009-01-05 1:01 ` Roman V. Shaposhnik 2009-01-07 6:24 ` [9fans] RFNOMNT and/or "least privilege" Dave Eckhardt 3 siblings, 0 replies; 16+ messages in thread From: erik quanstrom @ 2009-01-04 16:12 UTC (permalink / raw) To: 9fans > The "let's submit a patch and fix it" talk is scary. i haven't seen any such talk; and in any event, how can patches be scary? > All the pie-in-the-sky "gee it would be nice if it worked > like this, not that I'm actually using it" talk is unproductive. if it helps understand what's there, why it's there and what the real problems might be, i think there is value in it. perhaps i'm just not as smart as the rest of you, but full programs do not leap out of my head. they are preceeded by false starts, bad ideas and other people's ideas. it has take nearly forty years to get to this point. i'm sure that even at the labs, some pie-in-the-sky ideas have contributed to what plan 9 is now. - erik ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT 2009-01-04 7:08 RFNOMNT Russ Cox 2009-01-04 12:21 ` [9fans] RFNOMNT lucio 2009-01-04 16:12 ` erik quanstrom @ 2009-01-05 1:01 ` Roman V. Shaposhnik 2009-01-05 4:18 ` Skip Tavakkolian 2009-01-05 5:48 ` Russ Cox 2009-01-07 6:24 ` [9fans] RFNOMNT and/or "least privilege" Dave Eckhardt 3 siblings, 2 replies; 16+ messages in thread From: Roman V. Shaposhnik @ 2009-01-05 1:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sat, 2009-01-03 at 23:08 -0800, Russ Cox wrote: > The "let's submit a patch and fix it" talk is scary. Russ, with all due respect, life gets unnecessarily complicated when on one hand whenever I suggest something for discussion there's always a member of this list (you included) who asks me to show the code. But on the other hand, the comments like the above tend to suggest that such code would be written in vain anyway(*) It especially confusing when one doesn't even know who is in charge of reviewing officially submitted patches. If you are among reviewers the statements along the lines of "patches are scary" are quite scary. Thanks, Roman. (*) with a sole exception of people who maintain their own Plan9 codebase ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT 2009-01-05 1:01 ` Roman V. Shaposhnik @ 2009-01-05 4:18 ` Skip Tavakkolian 2009-01-05 4:01 ` lucio 2009-01-05 5:48 ` Russ Cox 1 sibling, 1 reply; 16+ messages in thread From: Skip Tavakkolian @ 2009-01-05 4:18 UTC (permalink / raw) To: 9fans i understood what Russ said to mean: patches -- for enhancements that "might" someday have a use or fixes that remove some perceived shortcoming lacking an actual need -- are scary. > On Sat, 2009-01-03 at 23:08 -0800, Russ Cox wrote: >> The "let's submit a patch and fix it" talk is scary. > > Russ, with all due respect, life gets unnecessarily complicated > when on one hand whenever I suggest something for discussion > there's always a member of this list (you included) who asks > me to show the code. But on the other hand, the comments like > the above tend to suggest that such code would be written in vain > anyway(*) > > It especially confusing when one doesn't even know who is in > charge of reviewing officially submitted patches. If you are > among reviewers the statements along the lines of "patches > are scary" are quite scary. > > Thanks, > Roman. > > (*) with a sole exception of people who maintain their own > Plan9 codebase ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT 2009-01-05 4:18 ` Skip Tavakkolian @ 2009-01-05 4:01 ` lucio 0 siblings, 0 replies; 16+ messages in thread From: lucio @ 2009-01-05 4:01 UTC (permalink / raw) To: 9fans > i understood what Russ said to mean: patches -- for enhancements that > "might" someday have a use or fixes that remove some perceived > shortcoming lacking an actual need -- are scary. Not if they are first discussed in the type of forum that is savvy to both the immediate effects and the hidden long term consequences. I think that was a misguided generalisation. If I had it at my fingertip, I would quote R.A. Heinlein's comment about democracy and dictatorship. I'd be curious to hear the Plan 9 developers' take on how significant they deem contributions from us peanut gallery, sometimes it seems they very much prefer us all to just go away, as Uriel seems to suggest. Other times they seem positively thrilled to have us around. A more consistent policy would be a lot easier to work with, whichever side it took. ++L PS: Of course, Russ does not represent all Plan 9 developers (I have a feeling and a deep respect for the fact that he may well often be the sole heir to the title of Plan 9 developer :-) and I am a very reluctant critic of someone whose contributions appear to have single-handedly shaped Plan 9. I'm sure that his outburst was nothing more than reaction under stressing circumstances. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT 2009-01-05 1:01 ` Roman V. Shaposhnik 2009-01-05 4:18 ` Skip Tavakkolian @ 2009-01-05 5:48 ` Russ Cox 1 sibling, 0 replies; 16+ messages in thread From: Russ Cox @ 2009-01-05 5:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I apologize for the tone of my first message. Skip put the words better in his rephrasing. I was speaking only for myself -- I have no part in applying patches to Plan 9 anymore. I submit changes the same as everyone else. I would hope that any patch changing the behavior of RFNOMNT would be based on someone's experience using the change for a while and exploring the consequences, rather than design on a mailing list. The various RFNOMNT threads seemed to have mostly the former, and then there was talk of a patch. That--talk of submitting patches to change subtle, low-level functionality without having any practical experience with the change--is what I found scary. Russ ^ permalink raw reply [flat|nested] 16+ messages in thread
* [9fans] RFNOMNT and/or "least privilege" 2009-01-04 7:08 RFNOMNT Russ Cox ` (2 preceding siblings ...) 2009-01-05 1:01 ` Roman V. Shaposhnik @ 2009-01-07 6:24 ` Dave Eckhardt 2009-01-07 13:15 ` sqweek 2009-01-08 19:29 ` Roman V. Shaposhnik 3 siblings, 2 replies; 16+ messages in thread From: Dave Eckhardt @ 2009-01-07 6:24 UTC (permalink / raw) To: 9fans > RFNOMNT, like everything in Plan 9, was put in because > someone needed to use it, not as a purely academic > exercise in adding features. Here is something which either I've misunderstood or is harder than I'd like. I have a machine which runs two private (password-protected) web servers on different ports. It is not the case that everybody who can log in to the machine should be able to read the content offered by those two servers. The web server infrastructure seems pretty focused on running as user "none", which makes sense as far as it goes, but I don't want none to be able to read the files served by the web servers because anybody who can log in to the machine can become none. What I've worked out so far is this. At boot time, the host owner (who is a member of a group which can access the bits) builds an approprate namespace for each of the web servers. In each case the hostowner starts up a wikifs which can read and modify the privileged information but which posts a world-mountable service descriptor in /srv. Once each web server is launched in a namespace which has mounted the descriptor, the descriptor is deleted from /srv. If all this happens before listen is run, I think the result is two environments which are both running as none but have access to the bits they need, without leaking that access to everybody else who runs as none. What does this have to do with RFNOMNT? For one thing, while I thought about using RFNOMNT to limit the ability of the a hijacked web server or its children to get at the rest of the system, lots of people demand the ability to rearrange their namespaces, e.g., wikipost bails out if it can't mount onto /mnt/wiki. But overall I wish I had more ability to set up "least privilege" execution domains, meaning process trees with exactly the privileges they need but no more. Or am I doing it all wrong? Dave Eckhardt ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT and/or "least privilege" 2009-01-07 6:24 ` [9fans] RFNOMNT and/or "least privilege" Dave Eckhardt @ 2009-01-07 13:15 ` sqweek 2009-01-08 19:29 ` Roman V. Shaposhnik 1 sibling, 0 replies; 16+ messages in thread From: sqweek @ 2009-01-07 13:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, Jan 7, 2009 at 3:24 PM, Dave Eckhardt <davide+p9@cs.cmu.edu> wrote: > The web server infrastructure seems pretty focused on running > as user "none", which makes sense as far as it goes, but I > don't want none to be able to read the files served by the > web servers because anybody who can log in to the machine can > become none. Pegasus[1] is different here, it has namespace seperation between virtual servers which run as arbitrary users. I can't really comment on other differences, as I'm not very familiar with httpd. Or pegasus, for that matter ;) I just read the intro the other day and it sounds like something you might be interested in. [1] http://plan9.aichi-u.ac.jp/pegasus/ -sqweek ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT and/or "least privilege" 2009-01-07 6:24 ` [9fans] RFNOMNT and/or "least privilege" Dave Eckhardt 2009-01-07 13:15 ` sqweek @ 2009-01-08 19:29 ` Roman V. Shaposhnik 2009-01-08 19:57 ` Charles Forsyth 1 sibling, 1 reply; 16+ messages in thread From: Roman V. Shaposhnik @ 2009-01-08 19:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 2009-01-07 at 01:24 -0500, Dave Eckhardt wrote: > > RFNOMNT, like everything in Plan 9, was put in because > > someone needed to use it, not as a purely academic > > exercise in adding features. > > Here is something which either I've misunderstood or is > harder than I'd like. [...] > What does this have to do with RFNOMNT? For one thing, while > I thought about using RFNOMNT to limit the ability of the a > hijacked web server or its children to get at the rest of the > system, lots of people demand the ability to rearrange their > namespaces, e.g., wikipost bails out if it can't mount onto > /mnt/wiki. The more I think about #X issue (especially in light of comments made by Russ) and RFNOMNT the more it dawns on me that I would really like to have a chat with whoever put it there ;-) (in moments like this, I also wish for good SCM history being available). It now seems, that if your process has a read/write access to a channel capable of speaking 9P not letting it mount that channel really doesn't accomplish much: whatever messages kernel would send on your behalf, you can send directly. There's no additional damage to be done. Thus, the first place, where RFNOMNT starts to make a difference, is when your jailed process spawns children. They are too, prevented from mounting stuff. Does it change security ramifications? I'd say for *channels* that speak 9P -- it doesn't. Thus, the only place where RFNOMNT start to *really* matter is restricting access to the devices in the #-namespace. Which, given its name, is a bit ironic. After all, accessing them is about *implicit* attach done by namec(), not an explicit mount. Now, as far as restricting access to the devices goes: RFNOMNT seems like too clumsy of a hammer: it either all or nothing (plus, all those weird exception noted in namec()). For example, if I wanted to create a jailed environment with access to a particular set of devices: I'm out of luck. So all in all, so far it seems that: 1. RFNOMNT is a bit of a misnomer 2. For what it is supposed to be useful (restricting access to kernel devices) it doesn't do a very convincing job. > But overall I wish I had more ability to set up "least privilege" > execution domains, meaning process trees with exactly the > privileges they need but no more. Ok, here are my thoughs: 1. so far, the #1 issue for proper jailing is really how to efficiently manage access rights to the kernel devices. 2. since at this point -- I'm almost convinced that: pretending that devices are channels capable of speaking 9P (and thus forcing the access to *always* be via the namespace) is not much better than what we currently have. So what are the options left to manage the access rights? Since devices are not channels (even pretend ones) you can't do the management via r/w permission on the channel itself. That leaves only RFNOMNT (which starts to look a bit ugly) and devattach(). >From a flexibility standpoint, though, I really wish I could do something like this: term% echo 'devallow |decpsPr' >> /proc/$pid/ctl # the above still doesn't matter # but after the next line it will term% rfork m term% ls '#p' '#P' '#s' # this works .... term% ls '#I' # this doesn't ls: #I: mount/attach disallowed The amount of code needed for such a change is trivial and it also has a benefit of managing those pesky exceptions in namec() in a much more explicit manner. Thanks, Roman. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT and/or "least privilege" 2009-01-08 19:29 ` Roman V. Shaposhnik @ 2009-01-08 19:57 ` Charles Forsyth 2009-01-08 19:45 ` Nathaniel W Filardo 2009-01-08 21:29 ` Roman V. Shaposhnik 0 siblings, 2 replies; 16+ messages in thread From: Charles Forsyth @ 2009-01-08 19:57 UTC (permalink / raw) To: 9fans >It now seems, that if your process has a read/write access to >a channel capable of speaking 9P not letting it mount that >channel really doesn't accomplish much: whatever messages kernel >would send on your behalf, you can send directly. note that if a Chan has once been mounted it can no longer be read or written except through devmnt. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT and/or "least privilege" 2009-01-08 19:57 ` Charles Forsyth @ 2009-01-08 19:45 ` Nathaniel W Filardo 2009-01-08 20:11 ` Charles Forsyth 2009-01-08 21:29 ` Roman V. Shaposhnik 1 sibling, 1 reply; 16+ messages in thread From: Nathaniel W Filardo @ 2009-01-08 19:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 596 bytes --] On Thu, Jan 08, 2009 at 07:57:42PM +0000, Charles Forsyth wrote: > >It now seems, that if your process has a read/write access to > >a channel capable of speaking 9P not letting it mount that > >channel really doesn't accomplish much: whatever messages kernel > >would send on your behalf, you can send directly. > > note that if a Chan has once been mounted it can no longer > be read or written except through devmnt. That's not much of a security guarantee since there's a race window when a channel is first posted to '#s' (e.g.), but yes, it's better than nothing. --nwf; [-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT and/or "least privilege" 2009-01-08 19:45 ` Nathaniel W Filardo @ 2009-01-08 20:11 ` Charles Forsyth 0 siblings, 0 replies; 16+ messages in thread From: Charles Forsyth @ 2009-01-08 20:11 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 384 bytes --] i was just pointing it out: i wasn't suggesting that it necessarily added security. (it was a response to the remark that a process could send arbitrary messages; not necessarily.) having said that, i'm not sure it's really a race, more of an ordering restriction: if you mount it before posting, i don't think you can get avoid the checks, so it can be much better than nothing. [-- Attachment #2: Type: message/rfc822, Size: 3489 bytes --] [-- Attachment #2.1.1: Type: text/plain, Size: 596 bytes --] On Thu, Jan 08, 2009 at 07:57:42PM +0000, Charles Forsyth wrote: > >It now seems, that if your process has a read/write access to > >a channel capable of speaking 9P not letting it mount that > >channel really doesn't accomplish much: whatever messages kernel > >would send on your behalf, you can send directly. > > note that if a Chan has once been mounted it can no longer > be read or written except through devmnt. That's not much of a security guarantee since there's a race window when a channel is first posted to '#s' (e.g.), but yes, it's better than nothing. --nwf; [-- Attachment #2.1.2: Type: application/pgp-signature, Size: 204 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] RFNOMNT and/or "least privilege" 2009-01-08 19:57 ` Charles Forsyth 2009-01-08 19:45 ` Nathaniel W Filardo @ 2009-01-08 21:29 ` Roman V. Shaposhnik 1 sibling, 0 replies; 16+ messages in thread From: Roman V. Shaposhnik @ 2009-01-08 21:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 2009-01-08 at 19:57 +0000, Charles Forsyth wrote: > >It now seems, that if your process has a read/write access to > >a channel capable of speaking 9P not letting it mount that > >channel really doesn't accomplish much: whatever messages kernel > >would send on your behalf, you can send directly. > > note that if a Chan has once been mounted it can no longer > be read or written except through devmnt. That's a good point. Mounted channels do introduce a third clause into this taxonomy -- channels which are only good for mounting. >From that standpoint they really start to look more like user-visible incarnations of #M, which would lump them into devices category. IOW, the appearance of extra security ramifications here is a bit deceiving. Thanks, Roman. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2009-01-08 21:29 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-01-04 7:08 RFNOMNT Russ Cox 2009-01-04 12:21 ` [9fans] RFNOMNT lucio 2009-01-04 17:04 ` Russ Cox 2009-01-04 18:27 ` lucio 2009-01-04 16:12 ` erik quanstrom 2009-01-05 1:01 ` Roman V. Shaposhnik 2009-01-05 4:18 ` Skip Tavakkolian 2009-01-05 4:01 ` lucio 2009-01-05 5:48 ` Russ Cox 2009-01-07 6:24 ` [9fans] RFNOMNT and/or "least privilege" Dave Eckhardt 2009-01-07 13:15 ` sqweek 2009-01-08 19:29 ` Roman V. Shaposhnik 2009-01-08 19:57 ` Charles Forsyth 2009-01-08 19:45 ` Nathaniel W Filardo 2009-01-08 20:11 ` Charles Forsyth 2009-01-08 21:29 ` Roman V. Shaposhnik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).