Re: [9fans] permissions
On Sun, Oct 17, 2010 at 12:59:04PM -0700, Benjamin Huntsman wrote: where you can't tweak things such that 100% of all administration activities can be performed remotely via drawterm... for some stuff like setting up disks, one still has to use the local physical terminal. I tend to add an exportfs of / late to the startup process which grabs the initial bootes namespace and posts it into /srv. Then I could do things like grab the server's keyfs without being at the console. It's not an ideal solution but it's not half bad and works well with the pieces available now. --nwf; pgp7ZvFzVaN2e.pgp Description: PGP signature
Re: [9fans] permissions
we use power switches in testing, in case we really wedge machines. Oh, is this a telnet capable mains switch? Is tehre a UK version, I have wanted such a thing for ages. -Steve
Re: [9fans] permissions
Oh, you can get them in the UK ...APC's stuff is telnet-able and very nice, but how many limbs can you afford?e.g. http://uk.insight.com/p/APCUA03N1K/apc-switched-rack-pdu-power-distribution-strip.html£306.99 ex VAT.HTH,Dave.On 18 Oct, 2010,at 10:05 AM, Steve Simon st...@quintile.net wrote: we use power switches in testing, in case we really wedge machines. Oh, is this a telnet capable mains switch? Is tehre a UK version, I have wanted such a thing for ages. -Steve
Re: [9fans] permissions
shoot high, aim low. i'm unimpressed by the 24 hour fitness centre where the locker room is umm how do i say it ... naughty. i need a tazer for sexual NO! only a few hours 'til it happens again. i don't care if you want you to display your shaved genitalia but that's not gonna fix my arm. i know i'm a shit hot speciman of kangaroo meat but give me a break. brucee On Mon, Oct 18, 2010 at 8:00 PM, Steve Simon st...@quintile.net wrote: we use power switches in testing, in case we really wedge machines. Oh, is this a telnet capable mains switch? Is tehre a UK version, I have wanted such a thing for ages. -Steve
Re: [9fans] permissions
Oh, is this a telnet capable mains switch? Is tehre a UK version, I have wanted such a thing for ages. Bay Technical Associates (baytech.net) has a huge variety of these, many take 220V, many are available on eBay, maybe the sets don't intersect but I think they do. You need to be a bit careful since a lot of what's on eBay is telnet-only (i.e., you probably don't want to deploy it on the Internet). Some of the older SSH-capable units have slow enough CPU's that you don't want to use an RSA key of more than 768 bits (and even that's noticeably slower than 512); if you use real SSL certs your CA may refuse to sign a key that small these days. Dave Eckhardt
Re: [9fans] permissions
if you want to crash everything in sight try a 4096 bit key. all i wanted was a pepsi ... brucee On Mon, Oct 18, 2010 at 4:07 AM, Dave Eckhardt davide...@cs.cmu.edu wrote: Oh, is this a telnet capable mains switch? Is tehre a UK version, I have wanted such a thing for ages. Bay Technical Associates (baytech.net) has a huge variety of these, many take 220V, many are available on eBay, maybe the sets don't intersect but I think they do. You need to be a bit careful since a lot of what's on eBay is telnet-only (i.e., you probably don't want to deploy it on the Internet). Some of the older SSH-capable units have slow enough CPU's that you don't want to use an RSA key of more than 768 bits (and even that's noticeably slower than 512); if you use real SSL certs your CA may refuse to sign a key that small these days. Dave Eckhardt
Re: [9fans] permissions
group membership checking is up to the particular file server. if it doesn't implement it, it wont be enforced. -Skip On Sat, Oct 16, 2010 at 10:35 PM, Benjamin Huntsman bhunts...@mail2.cu-portland.edu wrote: I probably need to go read the papers regarding permissions 10 more times, but this just doesn't seem right to me. I'm logged in as 'ben' via drawterm: cpu% cat /adm/users adm:adm:adm:sys,bootes,ben ben:ben::adm,sys bootes:bootes::ben glenda:glenda:glenda: none:none:: noworld:noworld:: sys:sys::glenda,bootes,ben upas:upas:: cpu% ls -l /dev/sd00 | grep nvram --rw-r- S 0 bootes bootes 512 Mar 7 2010 /dev/sd00/nvram cpu% cat /dev/sd00/nvram cat: can't open /dev/sd00/nvram: '/dev/sd00/nvram' permission denied cpu% Does that not say that if I'm a member of the bootes group, I should be able to cat that? Thanks in advance for not flogging me with the manual, and forgiveness for spending too much time in UNIX-land lately! :) -Ben
Re: [9fans] permissions
On Sun Oct 17 02:02:07 EDT 2010, skip.tavakkol...@gmail.com wrote: group membership checking is up to the particular file server. if it doesn't implement it, it wont be enforced. to elaborate: group permission is not implemented by any kernel file servers in the standard distribution. only a few non-kernel filesystems bother with group ownership. all of them are fileservers that store files on disk (e.g. fossil, kenfs). in theory, one could, involve the auth server in the process, so that a user could use the auth serve to prove he's part of a group, but nobody's done anything like that yet. - erik
Re: [9fans] permissions
to elaborate: group permission is not implemented by any kernel file servers in the standard distribution. And yet, it honors others permissions? I can set the r bit on others, and the cat then works... -Original Message- From: 9fans-boun...@9fans.net on behalf of erik quanstrom Sent: Sat 10/16/2010 11:19 PM To: 9fans@9fans.net Subject: Re: [9fans] permissions On Sun Oct 17 02:02:07 EDT 2010, skip.tavakkol...@gmail.com wrote: group membership checking is up to the particular file server. if it doesn't implement it, it wont be enforced. to elaborate: group permission is not implemented by any kernel file servers in the standard distribution. only a few non-kernel filesystems bother with group ownership. all of them are fileservers that store files on disk (e.g. fossil, kenfs). in theory, one could, involve the auth server in the process, so that a user could use the auth serve to prove he's part of a group, but nobody's done anything like that yet. - erik winmail.dat
Re: [9fans] permissions
to elaborate: group permission is not implemented by any kernel file servers in the standard distribution. And yet, it honors others permissions? I can set the r bit on others, and the cat then works... many fileservers assume that a user is always a member of a group of the same name. i wouldn't call that implementing groups. - erik
Re: [9fans] permissions
to elaborate: group permission is not implemented by any kernel file servers in the standard distribution. And yet, it honors others permissions? I can set the r bit on others, and the cat then works... Right. Aside from the persistent data file servers, like kfs, kenfs, and fossil (as Erik mentioned), there's not much that treats groups in the expected way. For example, all servers that use lib9p treat the group as really another user with privileges that might be different from the world. So in the case of a file that's owned by bootes bootes, the group permission is redundant. In the case of a file owned by bootes sys, then bootes gets the owner permission, the *user* sys gets the group permission and everyone else gets the world permission. Take a look at /sys/src/lib9p/uid.c to see the actual implementation. BLS
Re: [9fans] permissions
world permission. Take a look at /sys/src/lib9p/uid.c to see the actual implementation. amazing but true, if you're used to other other systems. you can find, read and undertand plan 9 code quickly. - erik
Re: [9fans] permissions
It's worth mentioning that the /adm/users contents have no effect whatsoever on the permission checking for /dev/nvram. ron
Re: [9fans] permissions
Right. Aside from the persistent data file servers, like kfs, kenfs, and fossil (as Erik mentioned), there's not much that treats groups in the expected way. So if you'll continue to pardon my asking, who exactly tells a given file server what constitutes a user or a group? In this particular instance, I'm running fossil (without Venti) as the filesystem. So then, doesn't /adm/users come from fossil? Wouldn't that mean that it's fossil's responsibility to enforce permissions? winmail.dat
Re: [9fans] permissions
Right. Aside from the persistent data file servers, like kfs, kenfs, and fossil (as Erik mentioned), there's not much that treats groups in the expected way. So if you'll continue to pardon my asking, who exactly tells a given file server what constitutes a user or a group? In this particular instance, I'm running fossil (without Venti) as the filesystem. So then, doesn't /adm/users come from fossil? Wouldn't that mean that it's fossil's responsibility to enforce permissions? the case of fossil and fossil+venti are the same. venti just changes how stuff is stored. in the current system, it's always the file server's responsiblity to maintain a list of users/groups as it sees fit. there is no central authority on users or groups. however, it's generally a very good idea to keep the user names in the authentication database in sync with your main file server. but there's no enforcement of this other than the host owner of the fileserver must exist in the auth database and the password must match. the host owner of the file server need not be in /adm/users at all! - erik
Re: [9fans] permissions
Right. Aside from the persistent data file servers, like kfs, kenfs, and fossil (as Erik mentioned), there's not much that treats groups in the expected way. So if you'll continue to pardon my asking, who exactly tells a given file server what constitutes a user or a group? In this particular instance, I'm running fossil (without Venti) as the filesystem. So then, doesn't /adm/users come from fossil? Wouldn't that mean that it's fossil's responsibility to enforce permissions? in the current system, it's always the file server's responsiblity to maintain a list of users/groups as it sees fit. there is no central authority on users or groups. however, it's generally a very good idea to keep the user names in the authentication database in sync with your main file server. but there's no enforcement of this other than the host owner of the fileserver must exist in the auth database and the password must match. the host owner of the file server need not be in /adm/users at all! Just to add a few bits. A file server only learns of the user on whose behalf the client is making requests in the attach message. From then on, the server can do whatever it wants with that information. It can implement the traditional user-group-world permissions. It can implement access control lists. It can do a user name translation and say that Bob will always get Alice's priviliges. It can do anything it wants, because it's handling the open request and will either succeed it for fail it and the client reacts accordingly. Another thing to note is that every file server can have a different set of users and groups. Your fossil file system has one set of users and groups you've defined. When you do a 9fs sources, you attach to another file server with a completely different set. In fact, there's no requirement that the intersection of the sets be non-empty. Finally, if we try to make the in-kernel file servers borrow another file server's user/group list, there are some annoying complications. If I have several file servers, which user list do I use? The first thought would be to have it know about /adm/users, but each process might have a different, or no, /adm/users in its name space. Plus, there's a chicken and egg problem. The server which gives you /dev/sd00/nvram has to approve of the attach when fossil wants to open its /dev/sd00/fossil, but until fossil has opened it, there's no way of knowing what's in /adm/users on that particular fossil. So for in-kernel file servers, it's best to look at them as hostowner and world and forget about groups. For lib9p based servers, you can link in a different implementation of hasperm() and get whatever permissions checking you want, but the default behavior is to assume that the named group has exactly one member: the group leader. BLS
Re: [9fans] permissions
...Plus, there's a chicken and egg problem. The server which gives you /dev/sd00/nvram has to approve of the attach when fossil wants to open its /dev/sd00/fossil, but until fossil has opened it, there's no way of knowing what's in /adm/users on that particular fossil. So for in-kernel file servers, it's best to look at them as hostowner and world and forget about groups. For lib9p based servers, you can link in a different implementation of hasperm() and get whatever permissions checking you want, but the default behavior is to assume that the named group has exactly one member: the group leader. Thank you for the clarification. That's exactly what I'm getting at. As you stated, /dev/sd00/* gets set up (especially where it's the only disk) before we have any idea of what the users/groups look like. Then, when you do a ls -l, it will show you users and groups that are listed in /adm/users. Chicken-and-egg, just like you said. Of course, that lands us in the current situation, where you can't tweak things such that 100% of all administration activities can be performed remotely via drawterm... for some stuff like setting up disks, one still has to use the local physical terminal. Don't get me wrong... I'm not complaining or finger-pointing; I'm just trying to fully understand the current state before attempting to poke at it. Thanks much!! -Ben winmail.dat
Re: [9fans] permissions
Chicken-and-egg, just like you said. Of course, that lands us in the current situation, where you can't tweak things such that 100% of all administration activities can be performed remotely via drawterm... for some stuff like setting up disks, one still has to use the local physical terminal. That starts to get into almost philosophical security issues. To some extent I consider this a good thing. Physical access is the ultimate privilige, so you need to physically protect your data to the extent that it's worth to you. If you've got physical protection anyway, then making physical access be required to do potentially destructive administration means you only one one avenue of compromise instead of physical and network. Having said that, because I have a combined CPU/auth/file server, I can, and sometimes do, cpu into it as the host owner and do administrative things that way. BLS
Re: [9fans] permissions
That starts to get into almost philosophical security issues. To some extent I consider this a good thing. Physical access is the ultimate privilige, so you need to physically protect your data to the extent that it's worth to you. If you've got physical protection anyway, then making physical access be required to do potentially destructive administration means you only one one avenue of compromise instead of physical and network. Having said that, because I have a combined CPU/auth/file server, I can, and sometimes do, cpu into it as the host owner and do administrative things that way. You're right, that's probably a philosophical discussion. As a real-world example, where I work, we've got a bunch of AIX servers out in our datacenter, which is a physically seperate building down the street. While we have physical access if we need it, generally speaking everything can be done remotely, including rebooting a system, because the HMC manages it and provides virtual serial consoles. But generally the HMC isn't used once the partition is up, as all administration can be done remotely, and a user can su to root if need be. I've been using the drawterm to hostowner trick too, but was thinking that since Plan 9 doesn't recognize a root-equivalent user, the opportunity is there to delegate permissions to any user (or group, ;) )such that they should be able to perform root-like tasks as themselves. If I were running a Plan 9 server on bare hardware in the datacenter, I wouldn't want to have to take a hike every time I needed to do certain activities, even though my key to the datacenter door grants me physical access should I need it. In this case, though, it's running under VMware ESXi, so the vSphere Client gives me remote access to the console, much as the HMC does for the AIX systems, but still... My point is that if one wants to open themselves up to another avenue of attack (albeit carefully controlled) by allowing such things to be done via network, they should be able to. So in that sense, maybe drawterm'ing to hostowner is the appropriate answer... Again, thanks for your responses!! -Ben winmail.dat
Re: [9fans] permissions
servers out in our datacenter, which is a physically seperate building down the street. While we have physical access if we need it, generally speaking everything can be done remotely, including rebooting a system, because the HMC manages it and provides virtual serial consoles. Real world considerations do often outweigh philosophical ones. At Coraid, we also have a means of accessing serial consoles via the network, and for most machines, that's about all the access that's needed. , but was thinking that since Plan 9 doesn't recognize a root-equivalent user, the opportunity is there to delegate permissions to any user (or group, ;) )such that they should be able to perform root-like tasks as themselves. It's certainly possible. You could even implement a multi-level security mechanism defining some devices as more sensitive than others. It wouldn't be too hard to implement groups as we expect for the lib9p applications, by rewriting hasperm() and rebuilding the apps. For the in-kernel servers, it would be a somewhat bigger task to go through them all and see how each one deals with permissions. For those that fall back to port/dev.c, the current rules treat the group permissions as applying to eve. But again, in principle, that could be changed, though I'm not sure what might break doing so. Still, it might be an interesting experiment. still... My point is that if one wants to open themselves up to another avenue of attack (albeit carefully controlled) by allowing such things to be done via network, they should be able to. So in that sense, maybe drawterm'ing to hostowner is the appropriate answer... That's certainly the easiest solution :) Again, thanks for your responses!! Always glad to help where I can. BLS
Re: [9fans] permissions
If I were running a Plan 9 server on bare hardware in the datacenter, I wouldn't want to have to take a hike every time I needed to do certain activities, even though my key to the datacenter door grants me physical access should I need it. In this case, though, it's running under VMware ESXi, so the vSphere Client gives me remote access to the console, much as the HMC does for the AIX systems, but still... My point is that if one wants to open themselves up to another avenue of attack (albeit carefully controlled) by allowing such things to be done via network, they should be able to. So in that sense, maybe drawterm'ing to hostowner is the appropriate answer... at coraid and at home, serial console /| cec and consolefs(8) has been sufficient for almost all cases, including rebooting the auth server. we use power switches in testing, in case we really wedge machines. i don't see an additional security concern, as logging in is the first step to contacting consolefs. - erik
Re: [9fans] permissions
set. In fact, there's no requirement that the intersection of the sets be non-empty. it's typically assumed that the intersection is not empty. So for in-kernel file servers, it's best to look at them as hostowner and world and forget about groups. For lib9p based servers, you can link in a different implementation of hasperm() and get whatever permissions checking you want, but the default behavior is to assume that the named group has exactly one member: the group leader. that is the current situation. but there is no reason that the auth protocol can't also inform the local kernel of the groups a user belongs to. this would tie groups to an auth domain, rather than a fileserver and would reduce some confusion, i think. - erik
[9fans] permissions
I probably need to go read the papers regarding permissions 10 more times, but this just doesn't seem right to me. I'm logged in as 'ben' via drawterm: cpu% cat /adm/users adm:adm:adm:sys,bootes,ben ben:ben::adm,sys bootes:bootes::ben glenda:glenda:glenda: none:none:: noworld:noworld:: sys:sys::glenda,bootes,ben upas:upas:: cpu% ls -l /dev/sd00 | grep nvram --rw-r- S 0 bootes bootes 512 Mar 7 2010 /dev/sd00/nvram cpu% cat /dev/sd00/nvram cat: can't open /dev/sd00/nvram: '/dev/sd00/nvram' permission denied cpu% Does that not say that if I'm a member of the bootes group, I should be able to cat that? Thanks in advance for not flogging me with the manual, and forgiveness for spending too much time in UNIX-land lately! :) -Ben
