Ognyan Kulev | 9 Mar 05:56
Picon
Favicon

Re: DogCows or Polymorphism in the Hurd

Marcus Brinkmann wrote:
> All objects are derived from a polytype class, which provides the
> following interfaces:
> 
> error_t poly_get_supported_types (obj_t obj, type_spec_t types[]);
> error_t poly_get_facet (obj_t, type_spec_t new_type, out: obj_t
> new_obj);

> Using the poly-type approach would remove all ambiguities: Applications
> would either see a file or a directory, but not both.  Applications who
> _know_ about hybrid types can use the new functions to switch facets
> explicitely.  If a user wants to use an application with a hybrid type,
> he will have to make his intent explicit by providing the node with the
> right facet type to the application.

I haven't catched up on this topic yet, but Hans Reiser has similar
problem with his reiser4 and multiple streams for one file:
<http://www.namesys.com/v4/v4.html#files_dirs>.  Perhaps it's worth to
learn what reiser4 does about it.

I remember that there was some proposal in POSIX to handle metadata as
files by using special file name component "..." (3 dots), e.g.
file/.../stat/mtime is file with last modified time. (Example is mine
and I don't know if the proposal was exactly for that.  The same applies
for the other examples in this mail.)  Anyway, this "..." was rejected,
but it could be used to access facets of any file (or directory).  So
directories could become real directories and not files in the Hurd and
their raw content may be accessed only by something like "dir/.../raw".
 Extended attributes can be accessed by this file thing too.  The tar.gz
case could be something like "package.tar.gz/.../facets/untar".
(Continue reading)

Marcus Brinkmann | 19 Mar 23:17
Picon
Favicon

What's in a group?

Hi,

I was pondering how to do terminals and sessions lately, and have
stumbled upon a semantically tricky issue I want your input on.

Managing users in isolation is rather straightforward: At creation, a
new user session will be constructed, for example from a template or a
template description.  Then some authentication token will be inserted
(can be a public fingerprint, for example, a la "authorized_keys").
That's basically it.

But what corresponds to the Unix group concept?  I have identified two
semantic uses for a "group":

1) Sharing information and authorization.  Ie, allow communication
   among users of the same group.

2) Provide durable storage that is not associated with any particular
   member of the group.

To fulfill the first requirement, a group should for example contain
some shared mutable name space, like a directory, that can be accessed
by all users.  To fulfill the second requirement, this shared name
space should be allocated not from any user's resource pool, but from
its own resource pool, the resource pool of the group.  This is
required to make the storage durable, even if some members of the
group are deleted from the system.

The second requirement can go away if we elect one user to be the
"group owner".  Destroying the "group owner" would then implicitely
(Continue reading)

Thomas Schwinge | 19 Mar 23:58
Picon

Re: What's in a group?

On Sun, Mar 19, 2006 at 11:17:48PM +0100, Marcus Brinkmann wrote:
> But what corresponds to the Unix group concept?  I have identified two
> semantic uses for a "group":
> 
> 1) Sharing information and authorization.  Ie, allow communication
>    among users of the same group.
> 
> 2) Provide durable storage that is not associated with any particular
>    member of the group.

3) Hindrance of the above.

#v+
$ groups
users foo
$ ls -l /tmp/not-for-fooers
-rw----rw- 1 thomas foo 0 Mar 19 23:45 /tmp/not-for-fooers
$ cat /tmp/not-for-fooers
cat: /tmp/not-for-fooers: Permission denied
#v-

(Obviously, this works only as long as you're not allowed to drop group
memberships.)

I don't know if there's a real-world example of this facility being used,
though.

Regards,
 Thomas
(Continue reading)

Marcus Brinkmann | 20 Mar 00:43
Picon
Favicon

Re: What's in a group?

At Sun, 19 Mar 2006 17:58:16 -0500,
Thomas Schwinge <tschwinge <at> gnu.org> wrote:
> 
> On Sun, Mar 19, 2006 at 11:17:48PM +0100, Marcus Brinkmann wrote:
> > But what corresponds to the Unix group concept?  I have identified two
> > semantic uses for a "group":
> > 
> > 1) Sharing information and authorization.  Ie, allow communication
> >    among users of the same group.
> > 
> > 2) Provide durable storage that is not associated with any particular
> >    member of the group.
> 
> 3) Hindrance of the above.
> 
> #v+
> $ groups
> users foo
> $ ls -l /tmp/not-for-fooers
> -rw----rw- 1 thomas foo 0 Mar 19 23:45 /tmp/not-for-fooers
> $ cat /tmp/not-for-fooers
> cat: /tmp/not-for-fooers: Permission denied
> #v-

I'm disgusted!

> I don't know if there's a real-world example of this facility being used,
> though.

I sincerely hope there isn't.  Otherwise it would rank very high in my
(Continue reading)

Michael D. Adams | 20 Mar 01:33
Picon

Re: What's in a group?

On 3/19/06, Marcus Brinkmann <marcus.brinkmann <at> ruhr-uni-bochum.de> wrote:
> At Sun, 19 Mar 2006 17:58:16 -0500,
> Thomas Schwinge <tschwinge <at> gnu.org> wrote:
> >
> > On Sun, Mar 19, 2006 at 11:17:48PM +0100, Marcus Brinkmann wrote:
> > > But what corresponds to the Unix group concept?  I have identified two
> > > semantic uses for a "group":
> > >
> > > 1) Sharing information and authorization.  Ie, allow communication
> > >    among users of the same group.
> > >
> > > 2) Provide durable storage that is not associated with any particular
> > >    member of the group.
> >
> > 3) Hindrance of the above.
> >
> > #v+
> > $ groups
> > users foo
> > $ ls -l /tmp/not-for-fooers
> > -rw----rw- 1 thomas foo 0 Mar 19 23:45 /tmp/not-for-fooers
> > $ cat /tmp/not-for-fooers
> > cat: /tmp/not-for-fooers: Permission denied
> > #v-
>
> I'm disgusted!
>
> > I don't know if there's a real-world example of this facility being used,
> > though.
>
(Continue reading)

Jonathan S. Shapiro | 20 Mar 04:10
Favicon
Gravatar

Re: What's in a group?

On Mon, 2006-03-20 at 00:43 +0100, Marcus Brinkmann wrote:
> At Sun, 19 Mar 2006 17:58:16 -0500,
> Thomas Schwinge <tschwinge <at> gnu.org> wrote:
> > 
> > On Sun, Mar 19, 2006 at 11:17:48PM +0100, Marcus Brinkmann wrote:
> > > But what corresponds to the Unix group concept?  I have identified two
> > > semantic uses for a "group":
> > > 
> > > 1) Sharing information and authorization.  Ie, allow communication
> > >    among users of the same group.
> > > 
> > > 2) Provide durable storage that is not associated with any particular
> > >    member of the group.
> > 
> > 3) Hindrance of the above.
> > 
> > #v+
> > $ groups
> > users foo
> > $ ls -l /tmp/not-for-fooers
> > -rw----rw- 1 thomas foo 0 Mar 19 23:45 /tmp/not-for-fooers
> > $ cat /tmp/not-for-fooers
> > cat: /tmp/not-for-fooers: Permission denied
> > #v-
> 
> I'm disgusted!

Oh, it gets better! For this scenario the access() system call will give
the wrong answer on many systems!

(Continue reading)

Jonathan S. Shapiro | 20 Mar 04:15
Favicon
Gravatar

Re: What's in a group?

On Sun, 2006-03-19 at 19:33 -0500, Michael D. Adams wrote:
> On 3/19/06, Marcus Brinkmann <marcus.brinkmann <at> ruhr-uni-bochum.de> wrote:
> > At Sun, 19 Mar 2006 17:58:16 -0500,
> > Thomas Schwinge <tschwinge <at> gnu.org> wrote:
> > >
> > > On Sun, Mar 19, 2006 at 11:17:48PM +0100, Marcus Brinkmann wrote:
> > > > But what corresponds to the Unix group concept?  I have identified two
> > > > semantic uses for a "group":
> > > >
> > > > 1) Sharing information and authorization.  Ie, allow communication
> > > >    among users of the same group.
> > > >
> > > > 2) Provide durable storage that is not associated with any particular
> > > >    member of the group.
> 
> What if I have secret surprise party plans for John who works on 5th
> floor and everyone on that floor is invited.  Everyone in the
> 5th_floor group should be able to read them *except* for John.  I
> could make a group 5th_floor_except_john...

I think that we are getting led astray here.

First, I think that Marcus has the semantics *almost* right. He has left
out the third requirement for conventional groups:

  3) Mere membership in a group should not convey the authority to
     add a new party to the group.

We need to look at that statement and agree that it is nonsense. If I am
in a group, I can proxy for you cheaply. This is *especially* true in an
(Continue reading)

Marcus Brinkmann | 20 Mar 11:31
Picon
Favicon

Re: What's in a group?

At Sun, 19 Mar 2006 22:15:17 -0500,
"Jonathan S. Shapiro" <shap <at> eros-os.org> wrote:
> First, I think that Marcus has the semantics *almost* right. He has left
> out the third requirement for conventional groups:
> 
>   3) Mere membership in a group should not convey the authority to
>      add a new party to the group.
> 
> We need to look at that statement and agree that it is nonsense. If I am
> in a group, I can proxy for you cheaply. This is *especially* true in an
> IDL-based system, where the proxy agent can be completely generic.
>
> This meant that there is no security motivation for preventing member A
> from adding a new member B.

But this is only true if A can already communicate with B at all.

This means that another part that potentially requires an
administrator is to set up the initial communication channel between A
and B.

It is true that users can communicate transitively.  If we want to
exploit this, we can model a very simple "communication grouping"
mechanism: The users of the system are organized in disjoint sets.
Any member of a set can communicate with any other member of the same
set.

However, from an administrator point of view, this is probably not the
most convenient way to organize users, and there may be other
parameters in the system configuration that ask for finer distinctions
(Continue reading)

Jonathan S. Shapiro | 20 Mar 20:28
Favicon
Gravatar

Re: What's in a group?

On Mon, 2006-03-20 at 11:31 +0100, Marcus Brinkmann wrote:
> > Actually, that is really a pretty nice thing, because it means that we
> > can reduce a group to a pair of capabilities:
> > 
> >   1. A capability to a source of storage, with the intention that
> >      this can be used by any member of the group.
> >
> >   2. A capability to a directory object that holds all of the objects
> >      that the group needs to share.
> > 
> > That's it. The only part of this that potentially requires an
> > administrator is if this storage has to be independent of the users.
> 
> The directory object requires a schedule.  Also, the storage by itself
> is useless, you need a service to manage it.  So, there may also be a
> file server (for example), also requiring a schedule.

Yes, I agree that a schedule is also needed, but no, you do not need any
additional services to "manage" this. If I wish to create an object
usable by the group, I use the group's storage and schedule, and then
bind a capability to the resulting object into the group's directory.
This includes subdirectories. Once I place the new object into the group
directory, other members of the group can use it.

Management may be helpful to assist programmers in getting the idiom
correct (which is important), but they are not functionally required.

> Note that this is not an abstract argument: I
> find running different group owned programs beside a directory and
> file server useful, especially in a multi-server object system!
(Continue reading)

Marcus Brinkmann | 20 Mar 23:16
Picon
Favicon

SSH revised

Hi,

Niels: I hope you don't mind that I suck you in to a Hurd design
question, but it's ssh related and that makes you my perfect target :)

I am stretching my neck out there, because I am as much a non-expert
on SSH and internetting as there can be.  I am counting on you guys!

I was thinking about how SSH would be done in an operating system
where the system does not retain full access to the user's computing
environment.  In particular, the SSH protocol goes from host based
authentication to starting user commands without a blink, and that's a
couple of leaps over barriers that we have introduced which may
provide a stumbling block to implementing ssh.

Let me give you my abstract models for terminals to have a solid
comparison: A terminal is a set of physical and logical devices.  At
log in, a capability to a directory (containing capabilities to these
devices and some extra info) is provided to the user's account, where
it will be attached to a session.  At log out, the terminal capability
is revoked by the system, the hardware is reset, and the next user can
log in (I left out a couple of details that are easy to work out).

I did not say where the user authentication happens.  We (Bas, Olaf
and I) have developed some ideas to do the authentication not in
system code, but in user code.  More on this another time (it's a
separate discussion).  But in the case of SSH, it doesn't really
matter.  Even if the authentication is done by the system, there is
still some part of the SSH protocol that the system can not do for the
user, for example executing a shell command.
(Continue reading)


Gmane