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
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
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:
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
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
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
It's worth mentioning that the /adm/users contents have no effect
whatsoever on the permission checking for /dev/nvram.
ron
2010/10/15 ron minnich rminn...@gmail.com:
2010/10/15 cinap_len...@gmx.de:
i wonder if making 9p work better over high latency connections is
even the right answer to the problem.
The reason I care is that the link from a CPU node to a file server on
blue gene is high latency. It might as
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
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
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
...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
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
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
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
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
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
On Sep 29, 2010, at 9:31 AM, Eric Van Hensbergen wrote:
Check http://www.livestream.com/iwp9 during the workshop. I'll post
an update to the list with whether or not I've got it working as well.
Any chance the videos can be pushed to youtube or some other reference site?
I've not been able
if you have the time, make your way down to portland oregon and visit
powell's city of books (http://www.powells.com).
On Sun, Oct 17, 2010 at 6:51 PM, Bruce Ellis bruce.el...@gmail.com wrote:
this has no technical information in it but may be a laugh for the IWP9
folk.
1) i had lunch at
19 matches
Mail list logo
