Dear ext4 developers,
Currently using ext3 on an usbstick seems to have a few drawbacks.
Consider the following situations:
1. Lend my usbstick to a college at work, but I don't want them to be
able to place files on it which I can't delete at work (where I don't
have root access).
2. Lend my usbstick to a friend and ask him/her to put another large
file on it before returning it.
One of the best solutions I can come up with is if the filesystem
would allow for a switch that would help ignore these permissions as
part of the filesystem. Any other solution would either require
specialized userspace solutions (which would probably make any
unpluggable usb device unsecure) or special options while mounting.
The latter would require root privileges and the UUID (for exmple)
would have to be known in advance.
Although using vfat is a solution, I would love to hear wether this is
considered a possible problem and wether it could be implementable at
a filesystem level?
I would be happy to discuss any and all possible solutions to these problems.
Greetings,
Bram
PS The only reason I don't want to use vfat is because I _think_ it's
old and don't think it's _cooool_.
On Wed, 2007-10-24 at 20:10 +0200, Bram Neijt wrote:
> One of the best solutions I can come up with is if the filesystem
> would allow for a switch that would help ignore these permissions as
> part of the filesystem.
Ignoring file permissions on removable, user-supplied media sounds like
something that ought to be done above the level of individual
filesystems, just like how we ignore device files and suid/sgid files in
certain cases. Maybe this is something that ought to be one level up
from the ext2/3/4 filesystem driver?
In any case, this raises interesting questions. If we ignore permissions
on removable media, then anyone logged into your work computer (to which
you do not have root access) will be able to muck about with your files.
Is that something you want?
Cheers,
Eric
First of all thank you for your reply.
To your question about allowing users to access/write to your files, I
would awnser yes. This is the whole point: allowing the owner of the
object full access without root privileges. I want to be able to
substitute a floppy or rewritable CD with an usbstick. Giving the
device to somebody will allow them to go any terminal with root access
and do anything they want anyway (unless I use encryption).
As I see it, the problem is that only the creator/owner of the
portable media knows what should be allowed by a non-root user when it
is plugged into another system. When I use it as a portable data
system for file interchange (like a rewritable cdrom or an
old-fashioned floppy), there is no way of telling the receiving system
that it should allow users to modify anything on this device. Without,
mind you, allowing any user of the system to modify anything on all
USB attached devices. Those devices may be usb disks with critical
work data that should be read-only for any work colleague but me.
One solution I can come up with, which would push the problem a level
higher, is by using a special disk label or UUID. But using a special
UUID for all "read and write anywhere" usb media, would probably
violate the whole "unique" idea about it ;-). A special label would
suffice, but may be perceived as ugly. So the best solution I can come
up with: make all attached media with a point at the end of their
label user owned.
Because I have the idea it should either be a globally agreed method
on every system I encounter or it should be something I can convey in
the filesystem/attributes when formatting, I thought I would ask
everybody on this list about it.
Greets,
Bram
PS As soon as anyboby feels that this discussion should not be held on
this mailinglist, please feel free to kindly redirect me to another
location.
On 10/25/07, Eric <[email protected]> wrote:
> On Wed, 2007-10-24 at 20:10 +0200, Bram Neijt wrote:
> > One of the best solutions I can come up with is if the filesystem
> > would allow for a switch that would help ignore these permissions as
> > part of the filesystem.
>
> Ignoring file permissions on removable, user-supplied media sounds like
> something that ought to be done above the level of individual
> filesystems, just like how we ignore device files and suid/sgid files in
> certain cases. Maybe this is something that ought to be one level up
> from the ext2/3/4 filesystem driver?
>
> In any case, this raises interesting questions. If we ignore permissions
> on removable media, then anyone logged into your work computer (to which
> you do not have root access) will be able to muck about with your files.
> Is that something you want?
>
> Cheers,
>
> Eric
>
>
>
On Wed, 2007-10-24 at 19:38 -0700, Eric wrote:
> On Wed, 2007-10-24 at 20:10 +0200, Bram Neijt wrote:
> > One of the best solutions I can come up with is if the filesystem
> > would allow for a switch that would help ignore these permissions as
> > part of the filesystem.
>
> Ignoring file permissions on removable, user-supplied media sounds like
> something that ought to be done above the level of individual
> filesystems, just like how we ignore device files and suid/sgid files in
> certain cases. Maybe this is something that ought to be one level up
> from the ext2/3/4 filesystem driver?
It would be a nice feature to implement at a higher level. A lot of
file systems do something like this.
> In any case, this raises interesting questions. If we ignore permissions
> on removable media, then anyone logged into your work computer (to which
> you do not have root access) will be able to muck about with your files.
> Is that something you want?
Mount options should override on-media permissions, but those overriding
permissions could still deny access to others:
mount -o uid=1000,gid=1000,fmask=137,dmask=027 /dev/sdb1 /mnt/usbstick
--
David Kleikamp
IBM Linux Technology Center
Thanks to Dave and Eric for their replies.
I'm moving the feature discussion to a higher level (pmount) and I've
opened a blueprint on it[1] with more words on why I think it's a
problem[2].
This means that I'm leaving this thread and closing it with this mail.
I would like to thank everybody who replied and read this, for their help.
Greetings,
Bram
[1] https://blueprints.launchpad.net/launchpad/+spec/usermount-permission-granting
[2] http://docs.google.com/Doc?id=dqqr5r6_41w7hfbx
On 10/25/07, Dave Kleikamp <[email protected]> wrote:
> On Wed, 2007-10-24 at 19:38 -0700, Eric wrote:
> > On Wed, 2007-10-24 at 20:10 +0200, Bram Neijt wrote:
> > > One of the best solutions I can come up with is if the filesystem
> > > would allow for a switch that would help ignore these permissions as
> > > part of the filesystem.
> >
> > Ignoring file permissions on removable, user-supplied media sounds like
> > something that ought to be done above the level of individual
> > filesystems, just like how we ignore device files and suid/sgid files in
> > certain cases. Maybe this is something that ought to be one level up
> > from the ext2/3/4 filesystem driver?
>
> It would be a nice feature to implement at a higher level. A lot of
> file systems do something like this.
>
> > In any case, this raises interesting questions. If we ignore permissions
> > on removable media, then anyone logged into your work computer (to which
> > you do not have root access) will be able to muck about with your files.
> > Is that something you want?
>
> Mount options should override on-media permissions, but those overriding
> permissions could still deny access to others:
>
> mount -o uid=1000,gid=1000,fmask=137,dmask=027 /dev/sdb1 /mnt/usbstick
>
> --
> David Kleikamp
> IBM Linux Technology Center
>
>
Bram Neijt ha scritto:
> Dear ext4 developers,
>
> Currently using ext3 on an usbstick seems to have a few drawbacks.
The problem of identifying a local resource (user ids) in a global
environment (many different computers) has a very simple solution:
consider uids locals when you transmit them, and use an _injective_ map
when mounting the drive to map uids in the drive to uids in the system.
The function has to be non-surjective because uids which differ on the
drive must differ in the system (this might not be a requirement but I
suppose many would appreciate it). This would, however, require support
from on-disk ext4 data format, which should provide a "table of
employied UIDS" to the ext4 kernel module, which should then do the
translation.
The injective map should, of course, be the identity function, unless
differently specified by users.
Is this feasible in anybody's opinion? It seems not such a conservative
extension so I suspect it might cause discussion :)
Alternatively, the ability to just provide a map file from uids and gids
of a disk to those of a system when mounting would be greatly
appreciated - but how to read it from the disk before mounting? Many
concerns arise. Has this already been discussed in the past?
Vincenzo
> The function has to be non-surjective because uids which differ on the
s/non-surjective/injective/ , i.e. it should not fuse different identities.
Sorry for double posting, will re-read e-mails before sending, in the
future :)
Vincenzo