lkml.org 
[lkml]   [2002]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] alternative API for raw devices


On Wed, 1 May 2002, Jeff Garzik wrote:

> Alexander Viro wrote:
>
> >Actual IO code is pretty much copied from old driver. The main differences:
> > * device is originally created with ownership/permissions of the
> > block device we'd used; you can chmod/chown it at any time,
> > obviously.
> >
>
> Tangent a little bit to partitions.
>
> Consider a filesystem which creates device nodes for N partitions on a
> spindle, "msdos_partition_fs". In a discussion a while back on
> permissions, you suggested that inheriting permissions from the base
> block device was the wrong way to go, and that (for now) 'uid' and
> 'gid' mount options were the best route.

> Is inheriting permissions coming back into style? Or am I reading too
> much into the permissions scheme you describe above?

Umm... Let me put it that way: partitions are persistent objects. We
have very legitimate reasons to assign equally persistent ownership and
permissions to them; moreover, different ownership and permissions.

For a raw device, bindings are not persistent. Unlike partitions, there's
simply no way to tell by device number what will it be associated with.
So persistent ownership/permissions for these guys make no sense whatsoever;
moreover, the data they give you access to is simply the contents of block
device; there's no such thing as "permissions to access this part".

So we simply set permissions/ownership in obviously safe way (i.e. such that
it doesn't change access rights compared to what we had before binding -
set ownership/permissions identical to these of block device) and leave
it to whoever had created a binding to do explicit chown/chmod if he
wants to do that.

Moreover, when we lift the restrictions on mount (i.e. creator of namespace
may mount on places he has sufficient access to, but filesystem needs to be
convinced that he deserves to mount it in the first place) we might allow
to create raw devices to everyone; in that case chmod/chown after mounting
is obviously the only safe scheme.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.060 / U:5.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site