A file-based interface for mount

A file-based interface for mount

[Grant Miner]

Would it make sense to use a file interface in the file system to 
control mounting?  Have a file that exists per-directory named ..mount 
(or something).  Then, to mount /dev/sda on /home, echo "/dev/sda rw" > 
/home/..mount
To unmount the file system, remove the line from the ..mounts file.  You 
could also do plan 9 layered mounts (with priorities) by putting 2 or 
more lines in that file.  The advantage is you could set access controls 
on each file to easily let non-root users perform mount at certain 
directories, and you don't need the mount and unmount commands anymore.

What do you think?

Re: A file-based interface for mount

[Hans Reiser]

Grant Miner wrote:

> Would it make sense to use a file interface in the file system to 
> control mounting?  Have a file that exists per-directory named ..mount 
> (or something).  Then, to mount /dev/sda on /home, echo "/dev/sda rw" 
> > /home/..mount
> To unmount the file system, remove the line from the ..mounts file.  
> You could also do plan 9 layered mounts (with priorities) by putting 2 
> or more lines in that file.  The advantage is you could set access 
> controls on each file to easily let non-root users perform mount at 
> certain directories, and you don't need the mount and unmount commands 
> anymore.
>
> What do you think?
>
>
>
Cool.  Probably not hard to write.  Can I get you to write it for 
Reiser4?  If so, we can discuss details (I will be delayed for a week in 
answering though due to traveling.)

-- 
Hans

Re: A file-based interface for mount

[Nikita Danilov]

Hans Reiser writes:
 > Grant Miner wrote:
 > 
 > > Would it make sense to use a file interface in the file system to 
 > > control mounting?  Have a file that exists per-directory named ..mount 
 > > (or something).  Then, to mount /dev/sda on /home, echo "/dev/sda rw" 
 > > > /home/..mount
 > > To unmount the file system, remove the line from the ..mounts file.  
 > > You could also do plan 9 layered mounts (with priorities) by putting 2 
 > > or more lines in that file.  The advantage is you could set access 
 > > controls on each file to easily let non-root users perform mount at 
 > > certain directories, and you don't need the mount and unmount commands 
 > > anymore.
 > >
 > > What do you think?
 > >
 > >
 > >
 > Cool.  Probably not hard to write.  Can I get you to write it for 
 > Reiser4?  If so, we can discuss details (I will be delayed for a week in 
 > answering though due to traveling.)

Adding new mount is not hard. Removing a mount through editing ..mount
is much harder, it's much easier to do something like 

echo "/dev/sda" > foo/..umount

But what exactly is an advantage of this interface?
If user is allowed to mount arbitrary file system at /some-place, it can
mount something containing suid binary and here we go.

 > 
 > -- 
 > Hans
 > 
 > 

Nikita.

Re: A file-based interface for mount

[Grant Miner]

>
> Adding new mount is not hard. Removing a mount through editing ..mount
> is much harder, it's much easier to do something like
>
> echo "/dev/sda" > foo/..umount
>
> But what exactly is an advantage of this interface?
> If user is allowed to mount arbitrary file system at /some-place, it can
> mount something containing suid binary and here we go.

Right, you wouldn't want users to be able to get setuid and setgid files 
and device nodes.  (I'd like to see setuid and setgid go away, since 
proper ACLs are more secure and nicer.)  Perhaps we would have 3 ACLs 
inherited from the parent node, and these would act as booleans to 
control if we allow device nodes, setuid, and setgid files to exist in 
some directory.  By default, these would all be false so that users can 
safely mount their own filesystems without security hazards.

This brings me to another question: in Reiser 4 there will probably be a 
common usage where you have a file, which is a newline separated list.  
Will there be a plug-in, when you access that file as a directory, you 
get each line in its own file?
Example:
#cat file.txt
line 1
line 2
line 3
#cat file.txt/0
line 1
#cat file.txt/2
line 3

> Cool.  Probably not hard to write.  Can I get you to write it for 
> Reiser4?  If so, we can discuss details (I will be delayed for a week 
> in answering though due to traveling.) 

I have not written any kernel code before.  I could try it.

Re: A file-based interface for mount

[Nikita Danilov]

Grant Miner writes:
 > 
 > >
 > > Adding new mount is not hard. Removing a mount through editing ..mount
 > > is much harder, it's much easier to do something like
 > >
 > > echo "/dev/sda" > foo/..umount
 > >
 > > But what exactly is an advantage of this interface?
 > > If user is allowed to mount arbitrary file system at /some-place, it can
 > > mount something containing suid binary and here we go.
 > 
 > Right, you wouldn't want users to be able to get setuid and setgid files 
 > and device nodes.  (I'd like to see setuid and setgid go away, since 
 > proper ACLs are more secure and nicer.)  Perhaps we would have 3 ACLs 
 > inherited from the parent node, and these would act as booleans to 
 > control if we allow device nodes, setuid, and setgid files to exist in 
 > some directory.  By default, these would all be false so that users can 
 > safely mount their own filesystems without security hazards.
 > 
 > This brings me to another question: in Reiser 4 there will probably be a 
 > common usage where you have a file, which is a newline separated list.  
 > Will there be a plug-in, when you access that file as a directory, you 
 > get each line in its own file?
 > Example:
 > #cat file.txt
 > line 1
 > line 2
 > line 3
 > #cat file.txt/0
 > line 1
 > #cat file.txt/2
 > line 3

Currently such functionality is supported by some pseudo files
(http://www.namesys.com/v4/pseudo.html), but in ad hoc manner:

strelka:~ # cd /data1/sh/..pagecache
strelka:/data1/sh/..pagecache # cat . ; echo
121 0 0 0 121
strelka:/data1/sh/..pagecache # ls
.  ..  clean  dirty  io  locked  nrpages
strelka:/data1/sh/..pagecache # cat nrpages; echo
121

 > 
 > > Cool.  Probably not hard to write.  Can I get you to write it for 
 > > Reiser4?  If so, we can discuss details (I will be delayed for a week 
 > > in answering though due to traveling.) 
 > 
 > I have not written any kernel code before.  I could try it.
 > 

Everybody did it for the first time. :)

Nikita.

Re: A file-based interface for mount

[Grant Miner]

> [See] http://www.namesys.com/v4/pseudo.html

Very awesome :)

>/mnt/1# # obtaining directory listing without getdents(2)
>/mnt/1# cat ./..readdir
>.
>..
>a
>b
>emacs
>ls
>foo

What happens if a filename has a newline char in it?

Re: A file-based interface for mount

[Hubert Chan]

>>>>> "Nikita" == Nikita Danilov <Nikita@Namesys.COM> writes:

[...]

Nikita> But what exactly is an advantage of this interface?  If user is
Nikita> allowed to mount arbitrary file system at /some-place, it can
Nikita> mount something containing suid binary and here we go.

I'm also wondering what advantages this interface would have.  As far
as I can tell, you lose more than you gain -- can't specify mount
options, file system type, etc.  It also seems very unintuitive to me.
From what I can see, the only advantages that you gain would be more
easily done by writing a custom SUID binary, which reads some
configuration file somewhere to determine if the user has proper
permissions, etc.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Advangates (A file-based interface for mount)

[Grant Miner]

Hubert Chan wrote:

>>>>>>"Nikita" == Nikita Danilov <Nikita@Namesys.COM> writes:
>>>>>>            
>>>>>>
>
>[...]
>
>Nikita> But what exactly is an advantage of this interface?  If user is
>Nikita> allowed to mount arbitrary file system at /some-place, it can
>Nikita> mount something containing suid binary and here we go.
>
>I'm also wondering what advantages this interface would have.  As far
>as I can tell, you lose more than you gain -- can't specify mount
>options, file system type, etc.  It also seems very unintuitive to me.
>>From what I can see, the only advantages that you gain would be more
>easily done by writing a custom SUID binary, which reads some
>configuration file somewhere to determine if the user has proper
>permissions, etc.
>  
>
Ideally, the file would use the same format as mtab (minus the mount point) so that it retains all mount options.  

Two reasons why this is nice:
First, the permissions of ..mount could be inherited, so that users would be able to mount things in their home directories but not system directories.

Second, the file format makes is intuitive for specifying layered mounts like plan 9.

Imagine a system where cat /..mount gives:
/dev/hda1 reiserfs rw 0 0

and cat /bin/..mount gives:
/usr/bin bind ro 0 0
/usr/local/bin bind ro 0 0
/opt/bin bind ro 0 0
/dev/hda1 reiserfs rw 0 0    <---- this one is inherited from /

Now, say you want to access file 'ls' out of /bin.  First, we look in /usr/bin because it's the top item.  If it is there, then we found it.  Otherwise, we keep going down the stack until we find it or reach the bottom and not find one.

If there are two instances of ls, say one in /opt/bin and one in /usr/bin, we use the one from /usr/bin because it is higher up.

If we write the file 'ls', it won't work if a copy of 'ls' exists in any of the read-only layers.  If the only instance of a file named 'ls' were in the filesystem on /dev/hda1, then it would get written there.  If there were no copy of ls in any layer, it would get created in the first read+write layer, in this case the filesystem on /dev/hda1.

It's really appealing with a per-process namespace.  Lets say I'm a user.  The OS layers my home directory read+write on MY instance of / , and a read-only copy of /bin, /usr/bin, etc. on MY instance of /bin .  Now, I don't need any environment variables like $HOME or $PATH.  I know (and more importantly, my programs know) that my home is always at / and my binaries always are in /bin .  I can throw my files in / .  They may be really stored in /home/users/grant or /mnt/foo/bar/etc but I don't have to know that.  One cool thing is this way users can install RPMs without affecting the main system files and quotas still apply.

Re: Advangates (A file-based interface for mount)

[Ragnar Kjørstad]

On Wed, Jul 09, 2003 at 04:32:44PM -0500, Grant Miner wrote:
> Two reasons why this is nice:
> First, the permissions of ..mount could be inherited, so that users would 
> be able to mount things in their home directories but not system 
> directories.

That would be nice, but having the correct permissions for the mount-
point is not sufficient from a security perspective.

I suppose the user would need read (and write) permissions to the
device/file he's mounting from? 

You would also need to avoid suid / sgid files and device-nodes - this
could probably be done by enforcing nosuid and nodev mount-flags. (Is
that enough? or are there filesystems that have suid-support but don't
support the nosuid flag?)

The last problem, which I don't see an easy solution for, is that the
filesystem-code in the kernel dosn't do sufficient data-checking that
it's safe to run it on user-controlled data. I'm sure that for most if
not all filesystems it will be possible to corrupt the metadata in a way
that will make the kernel crash or lock up - in some cases it may even
be possible to corrupt the data in such a way that it becomes a
security-problem? How could this be solved?

Personally I don't think it will ever be safe to let users mount from
user-controlled devices (files or block-devices) as long as the
filesystem-code is running in the kernel with full priveleges.

The only solution is to run the filesystem-code in userspace, like hurd
does.


Now. If all those problems were solved it would be possible to allow
users to mount any filesystem from any device on their writable
directories. But - I don't see why the mount-interface would need to be
changed? mount is already suid (on some systems, at least), and could
easily allow ordinary users to mount filesystems as well. (actually it
already does - but limited to filesystems listed in fstab with the
"user" option)

> Second, the file format makes is intuitive for specifying layered mounts 
> like plan 9.

A new mount interface is certainly no requirement for layered mounts -
if it's more intuitive or not is debatable. A central list of mounts may
become long and hard to read - but a decentralized list of mounts
certainly has it's drawbacks as well - how are you supposed to get a
complete list of what is mounted?



Basicly I think both user-mountable filesystems and layered mounts both
have their purposes, but theese features are ortogonal to a new mount-
interface. 



-- 
Ragnar Kjørstad

Re: Advangates (A file-based interface for mount)

[Oleg Drokin]

Hello!

On Thu, Jul 10, 2003 at 04:55:45AM +0200, Ragnar Kj?rstad wrote:

> You would also need to avoid suid / sgid files and device-nodes - this
> could probably be done by enforcing nosuid and nodev mount-flags. (Is
> that enough? or are there filesystems that have suid-support but don't
> support the nosuid flag?)

The nosuid/nodev/noexec/... stuff is enforced by VFS, not by individual filesystems.

Bye,
    Oleg

Re: Advangates (A file-based interface for mount)

[Timothy Webster]

Hi Grant, 

I really like this file-base mounting. Thanks for
contributing to reiserfs. I am look forward to the
many kool features possible with reiserfs4.

-tim. 


--- Grant Miner <mine0057@mrs.umn.edu> wrote:
> Hubert Chan wrote:
> 
> >>>>>>"Nikita" == Nikita Danilov
> <Nikita@Namesys.COM> writes:
> >>>>>>            
> >>>>>>
> >
> >[...]
> >
> >Nikita> But what exactly is an advantage of this
> interface?  If user is
> >Nikita> allowed to mount arbitrary file system at
> /some-place, it can
> >Nikita> mount something containing suid binary and
> here we go.
> >
> >I'm also wondering what advantages this interface
> would have.  As far
> >as I can tell, you lose more than you gain -- can't
> specify mount
> >options, file system type, etc.  It also seems very
> unintuitive to me.
> >>From what I can see, the only advantages that you
> gain would be more
> >easily done by writing a custom SUID binary, which
> reads some
> >configuration file somewhere to determine if the
> user has proper
> >permissions, etc.
> >  
> >
> Ideally, the file would use the same format as mtab
> (minus the mount point) so that it retains all mount
> options.  
> 
> Two reasons why this is nice:
> First, the permissions of ..mount could be
> inherited, so that users would be able to mount
> things in their home directories but not system
> directories.
> 
> Second, the file format makes is intuitive for
> specifying layered mounts like plan 9.
> 
> Imagine a system where cat /..mount gives:
> /dev/hda1 reiserfs rw 0 0
> 
> and cat /bin/..mount gives:
> /usr/bin bind ro 0 0
> /usr/local/bin bind ro 0 0
> /opt/bin bind ro 0 0
> /dev/hda1 reiserfs rw 0 0    <---- this one is
> inherited from /
> 
> Now, say you want to access file 'ls' out of /bin. 
> First, we look in /usr/bin because it's the top
> item.  If it is there, then we found it.  Otherwise,
> we keep going down the stack until we find it or
> reach the bottom and not find one.
> 
> If there are two instances of ls, say one in
> /opt/bin and one in /usr/bin, we use the one from
> /usr/bin because it is higher up.
> 
> If we write the file 'ls', it won't work if a copy
> of 'ls' exists in any of the read-only layers.  If
> the only instance of a file named 'ls' were in the
> filesystem on /dev/hda1, then it would get written
> there.  If there were no copy of ls in any layer, it
> would get created in the first read+write layer, in
> this case the filesystem on /dev/hda1.
> 
> It's really appealing with a per-process namespace. 
> Lets say I'm a user.  The OS layers my home
> directory read+write on MY instance of / , and a
> read-only copy of /bin, /usr/bin, etc. on MY
> instance of /bin .  Now, I don't need any
> environment variables like $HOME or $PATH.  I know
> (and more importantly, my programs know) that my
> home is always at / and my binaries always are in
> /bin .  I can throw my files in / .  They may be
> really stored in /home/users/grant or
> /mnt/foo/bar/etc but I don't have to know that.  One
> cool thing is this way users can install RPMs
> without affecting the main system files and quotas
> still apply.
> 
> 

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: Advangates (A file-based interface for mount)

[Toby Dickenson]

On Thursday 10 July 2003 03:55, Ragnar Kjørstad wrote:

> The last problem, which I don't see an easy solution for, is that the
> filesystem-code in the kernel dosn't do sufficient data-checking that
> it's safe to run it on user-controlled data. I'm sure that for most if
> not all filesystems it will be possible to corrupt the metadata in a way
> that will make the kernel crash or lock up - in some cases it may even
> be possible to corrupt the data in such a way that it becomes a
> security-problem? How could this be solved?

I would hope that the filesystems commonly used on removable media would try 
to defend against this. Is this hoping too much?

-- 
Toby Dickenson
http://www.geminidataloggers.com/people/tdickenson

Re: Advangates (A file-based interface for mount)

[Russell Coker]

On Fri, 11 Jul 2003 16:59, Toby Dickenson wrote:
> > not all filesystems it will be possible to corrupt the metadata in a way
> > that will make the kernel crash or lock up - in some cases it may even
> > be possible to corrupt the data in such a way that it becomes a
> > security-problem? How could this be solved?
>
> I would hope that the filesystems commonly used on removable media would
> try to defend against this. Is this hoping too much?

I expect that the VFAT and other drivers for MS based file systems would 
perform reasonably well in this regard.  MS-DOS floppy disks have a history 
of being stuffed up in every imaginable way.

Ext2/3 seem to do reasonably well in this regard.  It's been a long time since 
I saw an Ext2 file system that could kill a kernel.

ReiserFS does poorly in this regard.  I have just replaced some defective RAM 
in my laptop.  When the RAM got corrupted and corrupted a file system it was 
common for a ReiserFS file system to get in a state whereby mounting it or 
performing regular operations on it would crash the kernel (not even Oops it, 
but lock it solid).  The same machine also had Ext3 file systems which gave 
no problems under the same situation.

I have been told that it is not possible to make ReiserFS do all checks on 
such data.  I hope that Reiser4 will be more resiliant in this regard.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Advangates (A file-based interface for mount)

[Ragnar Kjørstad]

On Wed, Jul 09, 2003 at 11:31:56PM -0400, Barry, Christopher wrote:
> This is a bit off-topic

Well, this list has traditionally been very open to this kind of topics.

I should first point out that my knowledge of hurd is very limited; see
http://www.gnu.org/software/hurd/ for more authorative information.

> Does not the HURD enable users to all kinds of stuff, and it does not affect the core system? 

Yes, that's correct.

Hurd uses a microkernel, and other services, such as filesystems (or
translators, as they are called in hurd) run in a restricted
environment. This means that regular users can write and use their own
translator-code without affecting the stability of the system.


> Would this not be a cool thing in that environment. 

I'm not sure what you're refering to as "this" and "that environment",
but hurd is definitively "a cool thing". Unfortenately I think that is
all it is at this point. It's not ready for production use, and it
doesn't have neither a userbase or a developer-base close to what linux
has.

On the other hand it does have a very different architecture that allows
this kind of stuff - maybe in ten years hurd has matured. I think open
source software is flexible enough that once hurd reaches critical mass
all the drivers and features of linux can be ported to hurd relatively
quickly. (after all, they are license compatible)

> Does ReiserFS even work with the HURD? 

No.


-- 
Ragnar Kjørstad

RE: Advangates (A file-based interface for mount)

[Barry, Christopher]

This is a bit off-topic

Does not the HURD enable users to all kinds of stuff, and it does not affect the core system? Would this not be a cool thing in that environment. Does ReiserFS even work with the HURD? Do I even need to be talking here...;^)

oops, sorry. wrong conference room...

-C

-----Original Message-----
From: Ragnar Kjørstad [mailto:reiserfs@ragnark.vestdata.no]
Sent: Wednesday, July 09, 2003 10:56 PM
To: reiserfs-list@namesys.com
Subject: Re: Advangates (A file-based interface for mount)


On Wed, Jul 09, 2003 at 04:32:44PM -0500, Grant Miner wrote:
> Two reasons why this is nice:
> First, the permissions of ..mount could be inherited, so that users would 
> be able to mount things in their home directories but not system 
> directories.

That would be nice, but having the correct permissions for the mount-
point is not sufficient from a security perspective.

I suppose the user would need read (and write) permissions to the
device/file he's mounting from? 

You would also need to avoid suid / sgid files and device-nodes - this
could probably be done by enforcing nosuid and nodev mount-flags. (Is
that enough? or are there filesystems that have suid-support but don't
support the nosuid flag?)

The last problem, which I don't see an easy solution for, is that the
filesystem-code in the kernel dosn't do sufficient data-checking that
it's safe to run it on user-controlled data. I'm sure that for most if
not all filesystems it will be possible to corrupt the metadata in a way
that will make the kernel crash or lock up - in some cases it may even
be possible to corrupt the data in such a way that it becomes a
security-problem? How could this be solved?

Personally I don't think it will ever be safe to let users mount from
user-controlled devices (files or block-devices) as long as the
filesystem-code is running in the kernel with full priveleges.

The only solution is to run the filesystem-code in userspace, like hurd
does.


Now. If all those problems were solved it would be possible to allow
users to mount any filesystem from any device on their writable
directories. But - I don't see why the mount-interface would need to be
changed? mount is already suid (on some systems, at least), and could
easily allow ordinary users to mount filesystems as well. (actually it
already does - but limited to filesystems listed in fstab with the
"user" option)

> Second, the file format makes is intuitive for specifying layered mounts 
> like plan 9.

A new mount interface is certainly no requirement for layered mounts -
if it's more intuitive or not is debatable. A central list of mounts may
become long and hard to read - but a decentralized list of mounts
certainly has it's drawbacks as well - how are you supposed to get a
complete list of what is mounted?



Basicly I think both user-mountable filesystems and layered mounts both
have their purposes, but theese features are ortogonal to a new mount-
interface. 



-- 
Ragnar Kjørstad