[9fans] permissions

[9fans] permissions

[Benjamin Huntsman]

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

[Skip Tavakkolian]

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
<BHuntsman@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

[erik quanstrom]

On Sun Oct 17 02:02:07 EDT 2010, skip.tavakkolian@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

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

>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-bounces@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.tavakkolian@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



[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2954 bytes --]

Re: [9fans] permissions

[erik quanstrom]

> >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

[blstuart]

>>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

[erik quanstrom]

> 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

[ron minnich]

It's worth mentioning that the /adm/users contents have no effect
whatsoever on the permission checking for /dev/nvram.

ron

Re: [9fans] permissions

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

>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?


[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2544 bytes --]

Re: [9fans] permissions

[erik quanstrom]

> >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

[blstuart]

>> >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

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

>...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

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3172 bytes --]

Re: [9fans] permissions

[blstuart]

> 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

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]

>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

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3628 bytes --]

Re: [9fans] permissions

[erik quanstrom]

> 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

[Steve Simon]

> 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

[dave.l]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

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 <steve@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
>

[-- Attachment #2.1: Type: text/html, Size: 781 bytes --]

Re: [9fans] permissions

[Bruce Ellis]

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 <steve@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

[Dave Eckhardt]

> 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

[Bruce Ellis]

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+p9@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

[blstuart]

> 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

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

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;

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [9fans] permissions

[erik quanstrom]

> 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

Re: [9fans] permissions

[Russ Cox]

It's useful to be able to walk into useless directories.
If you couldn't walk into them, you couldn't bind over them.
(For example, /mail/fs.)

Re: [9fans] permissions

[Matthew Hannigan]

Is the distinction between x and r for directories
really that useful?   When does it matter?  I can
only think of "inbox" type directories.

I'm still thinking of being able to get rid of the
'x' permission on everything.

-Matt


Russ Cox wrote:
> 
> It's useful to be able to walk into useless directories.
> If you couldn't walk into them, you couldn't bind over them.
> (For example, /mail/fs.)

Re: [9fans] permissions

[Douglas A. Gwyn]

Matthew Hannigan wrote:
> Is the distinction between x and r for directories
> really that useful?   When does it matter?  I can
> only think of "inbox" type directories.
> I'm still thinking of being able to get rid of the
> 'x' permission on everything.

There is no canonically "right" answer to such a question.
If you think of the permission bits as providing per-file
(or per-entry) information that can be used by some
algorithm that enforces some security policy, then we
need to know the specific policy before being able to
give a specific answer.

It is certain that a process that can read an executable
image can in principle "execute" it by acting as an
interpreter.  Therefore for the "x" bit to be more useful
it needs to grant access to some additional capability.
In the case of a directory file, traditionally "r" and "x"
differ in that one means "can traverse as a pathname
component" while the other means "can read its entries".
These are definitely not the same thing.

Re: [9fans] permissions

[Russ Cox]

 From intro(5), ``A walk in a directory is regarded
as executing the directory, not reading it.''  Note it
says ``in'' and not ``into''.  The directory you were in
was still chmod +x.  I bet you can't cd .. back
out of your 664 directory.

Re: [9fans] permissions

[Lucio De Re]

On Thu, Oct 18, 2001 at 10:00:53AM -0400, Russ Cox wrote:
> 
> >From intro(5), ``A walk in a directory is regarded
> as executing the directory, not reading it.''  Note it
> says ``in'' and not ``into''.  The directory you were in
> was still chmod +x.  I bet you can't cd .. back
> out of your 664 directory.

Well, I'll be damned.  It is subtle and I'm not sure I like it that
way, I can't quite see what purpose it serves.  What you're saying
is that I may be able to create a new directory in the 664 directory
and, irrespective of _its_ permissions not walk into it.

I guess I'll do some learning once I can think of a reason to reboot
the file server :-)

Thanks, Russ.

++L

[9fans] permissions

[Lucio De Re]

I accidentally chmod'd 664 all entries in a directory, then cd'd
into the one directory, successfully.  Have I forgotten to "disallow"
unrestricted access to the fileserver, or should I worry about the
implementation of permissions?  This is a 2ed fileserver, and it's
been a long time since I last restarted it.

++L

PS: I was mucking about with PGP, version 263ii.  I have tweaked the
mods from Russ's site but the result really looks shoddy.  Still, if
anyone wants a working copy, the mods are quite simple, drop me a
line.