We're having a bit of a disagreement with Christoph Hellwig about the
way FUSE does (or should do) permission checking. Comments (either
way) are appreciated.
Here's my side of the story:
FUSE (filesystem in userspace) is designed to allow mounting an FS by
non-privileged users (it can also be used in the traditional way, but
that is uncontroversial and I'm not going to detail it here). The
philosophy behind this is that sometimes it's very convenient if a
program can have a filesystem as it's _output_.
Examples are:
- tar, zip, rar, etc[1] filesystem
- ftp[2], ssh[3], etc filesystem
- cvs[4], svn, etc filesystem
The common theme is that what you usually perform with some
specialized command can equally well (or sometimes better) be
performed with all the generic tools there are for file searching,
viewing, etc.
For example, the ftp and sftp commands actually give you a simulated
filesystem with a very limited shell (some variants have improved the
"simulation" by adding filename completion, etc).
With FUSE you can have the real thing and use your favourite tools on
remote or archived files. I think this fits in very well with the
"everything is a file" UNIX philosophy.
To allow this to work in the most convenient and secure way the
following must be satisfied:
1) User must not be able to modify files or directories in a way
which he otherwise could not do (e.g. mount a filesystem over
/bin)
2) Suid and device semantics should be disabled within the mount
3) No other user should have access to files under the mount, not
even root[5]
4) Access should not be further restricted for the owner of the
mount, even if permission bits, uid or gid would suggest
otherwise
5) As much of the available information should be exported via the
filesystem as possible
These are solved by:
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
2) Use nosuid,nodev mount options
3) In permission method of FUSE kernel module compare fsuid against
mounting user's ID, and return EACCES if they are not equal.
4) The filesystem daemon does not run with elevated permissions.
The kernel doesn't check file more in the permission method.
5) The filesystem daemon is free to fill in all file attributes to
any (sane) value, and the kernel won't modify these.
The debated part is 3) and 4), namely that normal permission checking
based on file mode is bypassed, and the mounting user has full
permission to all files, while other users have none.
This feature has been in FUSE from the start and thus has been very
well tested in real world scenarios. Also I have thought a lot about
how this could pose any kind of security threat, and as yet found no
such possiblity.
Despite this Christoph feels this behavior is unacceptable for a
filesystem, and wants me to remove this feature before merging FUSE
into mainline. I try to be open to ideas, but also feel strongly that
this is the Right Way, so I won't give up easily.
OK, open the flamethrowers!
Miklos
[1] http://www.inf.bme.hu/~mszeredi/avfs/ (CVS version required for
FUSE support)
[2] http://sourceforge.net/project/showfiles.php?group_id=121684&package_id=132803
[3] http://fuse.sourceforge.net/sshfs.html
[4] http://cvsfs.sourceforge.net/
[5] Obviously root cannot be restricted, but accidental access to
private data is still a good idea. E.g. root squashing by NFS servers
has a similar affect.
On Mon, Apr 11, 2005 at 04:43:32PM +0200, Miklos Szeredi wrote:
> 3) No other user should have access to files under the mount, not
> even root[5]
> [5] Obviously root cannot be restricted, but accidental access to
> private data is still a good idea. E.g. root squashing by NFS servers
> has a similar affect.
Could you explain a little more? I don't see the point in denying
access to root, but I also can't tell from your explanation whether you
do or not.
If I mount a filesystem using ssh, I want to be able to "sudo cp
foo.txt /etc" and not get an inexplicable permissions error.
I don't really see the point of this restriction, anyway. Could you
explain why this shouldn't be a matter of policy, and kept out of the
kernel? Have the userspace file servers default to putting restrictive
permissions on mounts unless requested otherwise.
I can think of plenty of uses for this.
> 4) Access should not be further restricted for the owner of the
> mount, even if permission bits, uid or gid would suggest
> otherwise
Similar questions.
--
Daniel Jacobowitz
CodeSourcery, LLC
> > 3) No other user should have access to files under the mount, not
> > even root[5]
>
> > [5] Obviously root cannot be restricted, but accidental access to
> > private data is still a good idea. E.g. root squashing by NFS servers
> > has a similar affect.
>
> Could you explain a little more? I don't see the point in denying
> access to root, but I also can't tell from your explanation whether you
> do or not.
Fuse by default does. This can be disabled by one of two mount
options: "allow_other" and "allow_root". The former implies the
later. These mount options are only allowed for mounting by root, but
this can be relaxed with a configuration option.
> If I mount a filesystem using ssh, I want to be able to "sudo cp
> foo.txt /etc" and not get an inexplicable permissions error.
If you can do that sudo, you can also modify the configuration and use
one of the mount options.
> I don't really see the point of this restriction, anyway. Could you
> explain why this shouldn't be a matter of policy, and kept out of the
> kernel? Have the userspace file servers default to putting restrictive
> permissions on mounts unless requested otherwise.
That's an option. However you can't restrict root that way, and you
need an extra directory, since permissions on the mountpoint are
ignored after the mount.
Restricting root is needed, so that a sysadmin won't accidently go
into a user's private mount (e.g. sshfs to some machine to which the
sysadmin otherwise has no access). Root can still gain access by
doing 'su me', but at least he will have a bad conscience. This is
not such a stupid idea as it first sounds IMO, and by default all NFS
servers exhibit a similar behavior (root squashing).
> > 4) Access should not be further restricted for the owner of the
> > mount, even if permission bits, uid or gid would suggest
> > otherwise
>
> Similar questions.
This behavior can be disabled by the "default_permissions" mount
option (wich is not privileged, since it adds restrictions). A FUSE
filesystem mounted by root (and not for private purposes) would
normally be done with "allow_other,default_permissions".
Does this answer your questions?
Thanks,
Miklos
On Mon, Apr 11, 2005 at 05:56:09PM +0200, Miklos Szeredi wrote:
> > > 3) No other user should have access to files under the mount, not
> > > even root[5]
> >
> > > [5] Obviously root cannot be restricted, but accidental access to
> > > private data is still a good idea. E.g. root squashing by NFS servers
> > > has a similar affect.
> >
> > Could you explain a little more? I don't see the point in denying
> > access to root, but I also can't tell from your explanation whether you
> > do or not.
>
> Fuse by default does. This can be disabled by one of two mount
> options: "allow_other" and "allow_root". The former implies the
> later. These mount options are only allowed for mounting by root, but
> this can be relaxed with a configuration option.
So the behavior that Cristoph was objecting to here is in fact
configurable?
> > I don't really see the point of this restriction, anyway. Could you
> > explain why this shouldn't be a matter of policy, and kept out of the
> > kernel? Have the userspace file servers default to putting restrictive
> > permissions on mounts unless requested otherwise.
>
> That's an option. However you can't restrict root that way, and you
> need an extra directory, since permissions on the mountpoint are
> ignored after the mount.
No, you need the userspace daemon to set the permissions on the root
directory of the new mount restrictively. What am I missing?
> Restricting root is needed, so that a sysadmin won't accidently go
> into a user's private mount (e.g. sshfs to some machine to which the
> sysadmin otherwise has no access). Root can still gain access by
> doing 'su me', but at least he will have a bad conscience. This is
> not such a stupid idea as it first sounds IMO, and by default all NFS
> servers exhibit a similar behavior (root squashing).
Root squashing is actually a much less obnoxious restriction. It means
that local uid 0 doesn't automatically correspond to remote uid 0.
> > > 4) Access should not be further restricted for the owner of the
> > > mount, even if permission bits, uid or gid would suggest
> > > otherwise
> >
> > Similar questions.
>
> This behavior can be disabled by the "default_permissions" mount
> option (wich is not privileged, since it adds restrictions). A FUSE
> filesystem mounted by root (and not for private purposes) would
> normally be done with "allow_other,default_permissions".
But why does the kernel need to know anything about this? Why can't
the userspace library present the permissions appropriately to the
kernel? I'm going to be pretty confused if I see a mode 666 file that
I can't even read. So will various programs.
Except for the allow_root bits, I think that having userspace handle
the issue entirely would cover both objections.
> Does this answer your questions?
More or less.
--
Daniel Jacobowitz
CodeSourcery, LLC
Miklos Szeredi wrote:
> 1) User must not be able to modify files or directories in a way
> which he otherwise could not do (e.g. mount a filesystem over
> /bin)
>
> 2) Suid and device semantics should be disabled within the mount
>
> 3) No other user should have access to files under the mount, not
> even root[5]
Why? I can see plenty of uses where I want a filesystem generated by
one user to be accessible by other users. That policy should not be
hard-coded into the kernel. It might be an option.
> 4) Access should not be further restricted for the owner of the
> mount, even if permission bits, uid or gid would suggest
> otherwise
Why? Surely you want to prevent writing to files which don't have the
writable bit set? A filesystem may also create append-only files -
and all users including the mount owner should be bound by that.
> 5) As much of the available information should be exported via the
> filesystem as possible
This is the root of the conflict. You are trying to overload the
permission bits and uid/gid to mean something different than they
normally do.
While it's convenient to see some "remote" information such as the
uid/gid in a tar file, are you sure it's a good idea to break the unix
permissions model - which will break some programs? (For example, try
editing a file with the broken semantics in an editor which checks the
uid/gid of the file against the current user).
For most virtual filesystems, the "remote" information does not map to
uid/gid in a particularly natural way anyway. So it seems odd to want
to break the unix permissions model just so that a small _subset_ of
virtual filesystems can use stat() as a way to get a bit of
information out, when other virtual filesystems (e.g. webdavfs) can't
put meaningful information in there, and would benefit from normal
unix permissions instead.
> 1) Only allow mount over a directory for which the user has write
> access (and is not sticky)
Seems good - but why not sticky? Mounting a user filesystem in
/tmp/user-xxx/my-mount-point seems not unreasonable - provided the
administrator can delete the directory (which is possible with
detachable mount points).
> 2) Use nosuid,nodev mount options
Of course. Ideally, make sure they appear to be set in /proc/mounts.
(root (or equivalent) should be able to create virtual filesystems
without these options, but probably they should be set by default even
for root, and clearable using suid,dev).
> 3) In permission method of FUSE kernel module compare fsuid against
> mounting user's ID, and return EACCES if they are not equal.
Bad. How do I, user A, then create a virtual filesystem which I want
user B to be able to access?
> 4) The filesystem daemon does not run with elevated permissions.
> The kernel doesn't check file more in the permission method.
I like the idea that the fs daemon doesn't need elevated permissions.
> 5) The filesystem daemon is free to fill in all file attributes to
> any (sane) value, and the kernel won't modify these.
Dangerous, because an administrative program might actually trust the
attributes to mean what they normally mean in the unix permissions model.
> The debated part is 3) and 4), namely that normal permission checking
> based on file mode is bypassed, and the mounting user has full
> permission to all files, while other users have none.
>
> This feature has been in FUSE from the start and thus has been very
> well tested in real world scenarios. Also I have thought a lot about
> how this could pose any kind of security threat, and as yet found no
> such possiblity.
Ok, but why do you prevent the useful behaviour of allowing access to
other users, when I want that? For example, I might export my current
project's database as a filesystem that I _want_ other users to be
able to read.
> Despite this Christoph feels this behavior is unacceptable for a
> filesystem, and wants me to remove this feature before merging FUSE
> into mainline. I try to be open to ideas, but also feel strongly that
> this is the Right Way, so I won't give up easily.
I agree with Christoph. It is a huge deviation from the unix
permissions model -- and it seems to prevent some useful applications
of FUSE so it's not clear why you want it.
-- Jamie
On Mon, Apr 11, 2005 at 07:22:57PM +0100, Jamie Lokier wrote:
> > 1) Only allow mount over a directory for which the user has write
> > access (and is not sticky)
>
> Seems good - but why not sticky? Mounting a user filesystem in
> /tmp/user-xxx/my-mount-point seems not unreasonable - provided the
> administrator can delete the directory (which is possible with
> detachable mount points).
Because then they could mount over /tmp. "and (is not sticky || is
owned by the user)" may be more appropriate.
--
Daniel Jacobowitz
CodeSourcery, LLC
> > > > 3) No other user should have access to files under the mount, not
> > > > even root[5]
> > >
> > > > [5] Obviously root cannot be restricted, but accidental access to
> > > > private data is still a good idea. E.g. root squashing by NFS servers
> > > > has a similar affect.
> > >
> > > Could you explain a little more? I don't see the point in denying
> > > access to root, but I also can't tell from your explanation whether you
> > > do or not.
> >
> > Fuse by default does. This can be disabled by one of two mount
> > options: "allow_other" and "allow_root". The former implies the
> > later. These mount options are only allowed for mounting by root, but
> > this can be relaxed with a configuration option.
>
> So the behavior that Cristoph was objecting to here is in fact
> configurable?
Christoph was not objcting to lack of choice, rather the opposite. He
would like to have only the "allow_other" behavior.
> > > I don't really see the point of this restriction, anyway. Could you
> > > explain why this shouldn't be a matter of policy, and kept out of the
> > > kernel? Have the userspace file servers default to putting restrictive
> > > permissions on mounts unless requested otherwise.
> >
> > That's an option. However you can't restrict root that way, and you
> > need an extra directory, since permissions on the mountpoint are
> > ignored after the mount.
>
> No, you need the userspace daemon to set the permissions on the root
> directory of the new mount restrictively. What am I missing?
You are basically right. This would conflict slightly with 5) in that
the attributes of the root would be lost.
> > Restricting root is needed, so that a sysadmin won't accidently go
> > into a user's private mount (e.g. sshfs to some machine to which the
> > sysadmin otherwise has no access). Root can still gain access by
> > doing 'su me', but at least he will have a bad conscience. This is
> > not such a stupid idea as it first sounds IMO, and by default all NFS
> > servers exhibit a similar behavior (root squashing).
>
> Root squashing is actually a much less obnoxious restriction. It means
> that local uid 0 doesn't automatically correspond to remote uid 0.
I don't agree that it's less obnoxious. Root squashing and a
restricted directory (-rwx------) would have exactly the same affect:
root is denied all access.
> > > > 4) Access should not be further restricted for the owner of the
> > > > mount, even if permission bits, uid or gid would suggest
> > > > otherwise
> > >
> > > Similar questions.
> >
> > This behavior can be disabled by the "default_permissions" mount
> > option (wich is not privileged, since it adds restrictions). A FUSE
> > filesystem mounted by root (and not for private purposes) would
> > normally be done with "allow_other,default_permissions".
>
> But why does the kernel need to know anything about this? Why can't
> the userspace library present the permissions appropriately to the
> kernel?
That is exactly what you should do if you use the default_permissions
options. You set the file mode, and the kernel checks the permission.
> I'm going to be pretty confused if I see a mode 666 file that I
> can't even read. So will various programs.
How would you get such I file? I don't understand.
> Except for the allow_root bits, I think that having userspace handle
> the issue entirely would cover both objections.
If I want to allow unprivileged users to be able to mount their
filesystems, then handling everything in userspace is not an option.
For example if you could mount a filesystem in which files have
user=root instead of your own user ID, you could probably confuse some
applications running as root, and cause information leak. That's
exactly why allow_root and allow_other are disabled for normal users.
The only safe option that I can imagine is that the kernel will reset
the user and group fields of the file attributes. This would again
require a kernel option, but would be far less useful IMO.
Thanks,
Miklos
On Mon, Apr 11, 2005 at 09:10:46PM +0200, Miklos Szeredi wrote:
> > Root squashing is actually a much less obnoxious restriction. It means
> > that local uid 0 doesn't automatically correspond to remote uid 0.
>
> I don't agree that it's less obnoxious. Root squashing and a
> restricted directory (-rwx------) would have exactly the same affect:
> root is denied all access.
That's considerably less obnoxious, because such directories are
comparatively rare; most files, root can still read. There are still
a couple unintuitive cases where root has less privelege than a
particular non-root user, of course. But your model gives root
normally fewer privileges than the user that mounted th e FS.
> > But why does the kernel need to know anything about this? Why can't
> > the userspace library present the permissions appropriately to the
> > kernel?
>
> That is exactly what you should do if you use the default_permissions
> options. You set the file mode, and the kernel checks the permission.
So why not make default_permissions a feature of the userspace?
> > I'm going to be pretty confused if I see a mode 666 file that I
> > can't even read. So will various programs.
>
> How would you get such I file? I don't understand.
The permissions exposed by the FUSE layer apparently don't correspond
to what local users can do with them. That's the problem here. It may
be that I'm completely misunderstanding you - but from what you've
described, the userspace daemon can mark a file's permissions as 666,
and then with allow_other and allow_root off no one else will be able
to read it, despite those permissions.
> > Except for the allow_root bits, I think that having userspace handle
> > the issue entirely would cover both objections.
>
> If I want to allow unprivileged users to be able to mount their
> filesystems, then handling everything in userspace is not an option.
> For example if you could mount a filesystem in which files have
> user=root instead of your own user ID, you could probably confuse some
> applications running as root, and cause information leak. That's
> exactly why allow_root and allow_other are disabled for normal users.
>
> The only safe option that I can imagine is that the kernel will reset
> the user and group fields of the file attributes. This would again
> require a kernel option, but would be far less useful IMO.
I think we've got a boundary problem here. You are exposing some
arbitrary, user-supplied values in the permissions, and then performing
sanity checks at access time; I'm suggesting performing the sanity
checking on the other side, when the permissions are supplied to the
kernel by the daemon.
Why would it be less useful to show files that have been "created" by a
user as owned by that user? Or files that the user has requested no
other users be able to write as unwritable by group/other? Sure, it
makes your tarfs a little less mapped onto the tar file. But that's
one of the recurring objections to implementing archivers as
filesystems: the ownership in the archive is _not_ relevant to the
mounted copy.
--
Daniel Jacobowitz
CodeSourcery, LLC
> > 1) User must not be able to modify files or directories in a way
> > which he otherwise could not do (e.g. mount a filesystem over
> > /bin)
> >
> > 2) Suid and device semantics should be disabled within the mount
> >
> > 3) No other user should have access to files under the mount, not
> > even root[5]
>
> Why? I can see plenty of uses where I want a filesystem generated by
> one user to be accessible by other users. That policy should not be
> hard-coded into the kernel. It might be an option.
It is.
> > 4) Access should not be further restricted for the owner of the
> > mount, even if permission bits, uid or gid would suggest
> > otherwise
>
> Why? Surely you want to prevent writing to files which don't have the
> writable bit set? A filesystem may also create append-only files -
> and all users including the mount owner should be bound by that.
You are right. This is indeed possible optionally. I'm saying that
maybe the filesystem owner _does_ _not_ want any more restrictions
despite the attributes. Consider a tar file in which there is a file
owned by 'root' and having permissions (-rw-------). If you have read
access to the tar file, you can obviously actually read the file
inside the tar file despite it's permissions.
> > 5) As much of the available information should be exported via the
> > filesystem as possible
>
> This is the root of the conflict. You are trying to overload the
> permission bits and uid/gid to mean something different than they
> normally do.
Yes.
> While it's convenient to see some "remote" information such as the
> uid/gid in a tar file, are you sure it's a good idea to break the unix
> permissions model - which will break some programs? (For example, try
> editing a file with the broken semantics in an editor which checks the
> uid/gid of the file against the current user).
Why would a program do that? In fact I've not come accross such a
program yet, so this is pretty theoretical. On the other hand even if
such a program existed, the filesystem could still have an option to
change uid/gid/mode on all files to something 'standard' (like
uid/gid/umask options for stupid filesystems).
> For most virtual filesystems, the "remote" information does not map to
> uid/gid in a particularly natural way anyway.
Tar archives of local disk? Sshfs to server with which you have
shared passwd files? These are not made up examples.
> So it seems odd to want to break the unix permissions model just so
> that a small _subset_ of virtual filesystems can use stat() as a way
> to get a bit of information out, when other virtual filesystems
> (e.g. webdavfs) can't put meaningful information in there, and would
> benefit from normal unix permissions instead.
But where there's no meaningful information, you don't need to make it
up. What I'm proposing doesn't limit the filesystem in any way.
There's an option to leave permission checking to the kernel, then all
you need to worry about is setting the mode bits. That is perfectly
OK.
> > 1) Only allow mount over a directory for which the user has write
> > access (and is not sticky)
>
> Seems good - but why not sticky? Mounting a user filesystem in
> /tmp/user-xxx/my-mount-point seems not unreasonable - provided the
> administrator can delete the directory (which is possible with
> detachable mount points).
Yes. The only thing you're not allowed is to mount on /tmp, for
obvious reasons :)
> > 2) Use nosuid,nodev mount options
>
> Of course. Ideally, make sure they appear to be set in /proc/mounts.
They are in fact set by the fusermount userspace utility. So there's
no extra kernel magic involved.
> (root (or equivalent) should be able to create virtual filesystems
> without these options, but probably they should be set by default even
> for root, and clearable using suid,dev).
That is exactly how it works.
> > 3) In permission method of FUSE kernel module compare fsuid against
> > mounting user's ID, and return EACCES if they are not equal.
>
> Bad. How do I, user A, then create a virtual filesystem which I want
> user B to be able to access?
But together with the option to set arbitary uid/gid on the files
within your mounts this could be abused, I think. So either this or
that. If someone really needs this I can implement another option.
> > 4) The filesystem daemon does not run with elevated permissions.
> > The kernel doesn't check file more in the permission method.
>
> I like the idea that the fs daemon doesn't need elevated permissions.
>
> > 5) The filesystem daemon is free to fill in all file attributes to
> > any (sane) value, and the kernel won't modify these.
>
> Dangerous, because an administrative program might actually trust the
> attributes to mean what they normally mean in the unix permissions model.
Yes, I agree with you fully. This is exactly why other users
including root are not allowed access to the mount.
> > The debated part is 3) and 4), namely that normal permission checking
> > based on file mode is bypassed, and the mounting user has full
> > permission to all files, while other users have none.
> >
> > This feature has been in FUSE from the start and thus has been very
> > well tested in real world scenarios. Also I have thought a lot about
> > how this could pose any kind of security threat, and as yet found no
> > such possiblity.
>
> Ok, but why do you prevent the useful behaviour of allowing access to
> other users, when I want that? For example, I might export my current
> project's database as a filesystem that I _want_ other users to be
> able to read.
Yes, this is a valid point. I'll see how an option allowing this
would look like. I think it can be coded up in a few lines.
> > Despite this Christoph feels this behavior is unacceptable for a
> > filesystem, and wants me to remove this feature before merging FUSE
> > into mainline. I try to be open to ideas, but also feel strongly that
> > this is the Right Way, so I won't give up easily.
>
> I agree with Christoph. It is a huge deviation from the unix
> permissions model
It is. But it's still less confusing to allow something that you'd
think is not allowed, than the opposite.
> -- and it seems to prevent some useful applications of FUSE so it's
> not clear why you want it.
I don't want to prevent any usage that is safe and secure. What
Christoph wants _would_ prevent some valid applications.
Thanks,
Miklos
Greetings, gentlemen,
On 11 April 2005 23:10, you wrote:
>
> Christoph was not objcting to lack of choice, rather the opposite. He
> would like to have only the "allow_other" behavior.
I think I could sched some light on this option.
It was needed when I was implementing SMB-to-FS connector (basically mapping
msnet into filesystem hierarchy), using smbmount to actually mount shares
over fuse-supported directory tree. smbmount (and sbmnt, in turn) needs to be
able to access mountpoint, and, unfortunately, this access is done under
setuid(0). allow_other can't be used in many cases, f.e. when user mounts
MSNet tree over /mnt (and can't protect /mnt with standard and proper
attributes ).
--
Managing your Territory since the dawn of times ...
> > > Root squashing is actually a much less obnoxious restriction. It means
> > > that local uid 0 doesn't automatically correspond to remote uid 0.
> >
> > I don't agree that it's less obnoxious. Root squashing and a
> > restricted directory (-rwx------) would have exactly the same affect:
> > root is denied all access.
>
> That's considerably less obnoxious, because such directories are
> comparatively rare; most files, root can still read. There are still
> a couple unintuitive cases where root has less privelege than a
> particular non-root user, of course. But your model gives root
> normally fewer privileges than the user that mounted th e FS.
That is exactly the intended effect. If I'm at my work machine (where
I'm not an admin unfortunately) and I mount my home machine with sshfs
(because FUSE is installed fortunately :), then I bloody well don't
want the sysadmin or some automated script of his to go mucking under
the mountpoint.
> > > But why does the kernel need to know anything about this? Why can't
> > > the userspace library present the permissions appropriately to the
> > > kernel?
> >
> > That is exactly what you should do if you use the default_permissions
> > options. You set the file mode, and the kernel checks the permission.
>
> So why not make default_permissions a feature of the userspace?
I don't understand. The userspace can't enforce the permissions.
That can only be done by the kernel. The "default_permissions" option
tells the kernel to enforce permissions based on file mode. If the
option is missing, then the kernel does not enforce those permissions.
> > > I'm going to be pretty confused if I see a mode 666 file that I
> > > can't even read. So will various programs.
> >
> > How would you get such I file? I don't understand.
>
> The permissions exposed by the FUSE layer apparently don't correspond
> to what local users can do with them. That's the problem here. It may
> be that I'm completely misunderstanding you - but from what you've
> described, the userspace daemon can mark a file's permissions as 666,
> and then with allow_other and allow_root off no one else will be able
> to read it, despite those permissions.
Other users won't be able to read even the attributes, so I don't see
it as a problem. It will be a special "no go" directory for anyone
except the mount owner.
> > > Except for the allow_root bits, I think that having userspace handle
> > > the issue entirely would cover both objections.
> >
> > If I want to allow unprivileged users to be able to mount their
> > filesystems, then handling everything in userspace is not an option.
> > For example if you could mount a filesystem in which files have
> > user=root instead of your own user ID, you could probably confuse some
> > applications running as root, and cause information leak. That's
> > exactly why allow_root and allow_other are disabled for normal users.
> >
> > The only safe option that I can imagine is that the kernel will reset
> > the user and group fields of the file attributes. This would again
> > require a kernel option, but would be far less useful IMO.
>
> I think we've got a boundary problem here. You are exposing some
> arbitrary, user-supplied values in the permissions, and then performing
> sanity checks at access time; I'm suggesting performing the sanity
> checking on the other side, when the permissions are supplied to the
> kernel by the daemon.
Well the sanity check on the "server" side is always enforced. You
can't "trick" sftp or ftp to not check permissions. So checking on
the "client" side too (where the fuse daemon is running) makes no
sense, does it?
> Why would it be less useful to show files that have been "created" by a
> user as owned by that user? Or files that the user has requested no
> other users be able to write as unwritable by group/other? Sure, it
> makes your tarfs a little less mapped onto the tar file. But that's
> one of the recurring objections to implementing archivers as
> filesystems: the ownership in the archive is _not_ relevant to the
> mounted copy.
So this objection is now dealt with. Is that a problem?
Thanks,
Miklos
Miklos Szeredi wrote:
> That is exactly the intended effect. If I'm at my work machine (where
> I'm not an admin unfortunately) and I mount my home machine with sshfs
> (because FUSE is installed fortunately :), then I bloody well don't
> want the sysadmin or some automated script of his to go mucking under
> the mountpoint.
I think that would be _much_ nicer implemented as a mount which is
invisible to other users, rather than one which causes the admin's
scripts to spew error messages. Is the namespace mechanism at all
suitable for that?
It would also be nice to generalise and have virtual filesystems which
are able to present different views to different users. Can FUSE do
that already - is the userspace part told which user is doing each
operation? With that, the desire for virtual filesystems which cannot
be read by your sysadmin (by accident) is easy to satisfy - and that
kind of mechanism would probably be acceptable to all.
-- Jamie
On Mon, Apr 11, 2005 at 09:56:29PM +0200, Miklos Szeredi wrote:
> Well the sanity check on the "server" side is always enforced. You
> can't "trick" sftp or ftp to not check permissions. So checking on
> the "client" side too (where the fuse daemon is running) makes no
> sense, does it?
That argument doesn't make much sense to me. But we're at the end of
my useful contributions to this discussion; I'm going to be quiet now
and hope some folks who know more about filesystems have more useful
responses.
--
Daniel Jacobowitz
CodeSourcery, LLC
> I think that would be _much_ nicer implemented as a mount which is
> invisible to other users, rather than one which causes the admin's
> scripts to spew error messages.
Spew is a strong word. It'll get a single EACCES at the mountpoint.
The same is true for directories not accessible by 'nobody' under an
NFS mount exported with root squash.
> Is the namespace mechanism at all suitable for that?
It is certainly the right tool for this. However currently private
namespaces are quite limited. The only sane usage I can think of is
that before mounting the user starts a shell with CLONE_NS, and does
the mount in this. However all the other programs he already has
running (editor, browser, desktop environment) won't be able to access
the mount.
Shared subtrees and more support in userspace tools is needed before
private namespaces can become really useful.
> It would also be nice to generalise and have virtual filesystems which
> are able to present different views to different users. Can FUSE do
> that already - is the userspace part told which user is doing each
> operation?
Yes.
> With that, the desire for virtual filesystems which cannot be read
> by your sysadmin (by accident) is easy to satisfy - and that kind of
> mechanism would probably be acceptable to all.
The problem is that this way the responsibility goes to the userspace
program, which can't be trusted.
Either the kernel has to enforce that uid/gid on each file are set to
the mount owner, or the kernel has to enforce that no other user has
access to the mountpoint. Some policy _must_ be kept in kernel.
I think both these policies have valid uses, so I wouldn't want to
limit FUSE to a single one. Hmm?
Thanks,
Miklos
> > Well the sanity check on the "server" side is always enforced. You
> > can't "trick" sftp or ftp to not check permissions. So checking on
> > the "client" side too (where the fuse daemon is running) makes no
> > sense, does it?
>
> That argument doesn't make much sense to me. But we're at the end of
> my useful contributions to this discussion; I'm going to be quiet now
> and hope some folks who know more about filesystems have more useful
> responses.
I'm sorry if this isn't clear enough. My explanatory powers are not
very strong, so please bear with me.
Imagine an sftp session. You list the files on the remote server.
You want download a file for which there are very limited permission
(e.g. only readable to owner). You don't _know_ if you are the owner
since the uid on the file does not ring any bells, but you still try,
since you want that file badly. And you succeed.
Would it make sense if the sftp client would try to interpret the
uid/gid/permission on each file? Obviously not.
The same is true for the case when you mount an sshfs. Since you
entered your password (or have a passwordless login to the server) you
are authorized to browse the files on the server, but only with the
capabilities you have there as a user. The server does the
authorization. The same is true for an NFS mount btw. It's not the
client that checks the permissions.
So do you see why I argue in favor of having an option _not_ to check
permissions on the client by the kernel?
Thanks,
Miklos
On Mon, Apr 11, 2005 at 17:56:09 +0200, Miklos Szeredi wrote:
> > Could you explain a little more? I don't see the point in denying
> > access to root, but I also can't tell from your explanation whether you
> > do or not.
>
> Fuse by default does. This can be disabled by one of two mount
> options: "allow_other" and "allow_root". The former implies the
> later. These mount options are only allowed for mounting by root, but
> this can be relaxed with a configuration option.
>
> > If I mount a filesystem using ssh, I want to be able to "sudo cp
> > foo.txt /etc" and not get an inexplicable permissions error.
>
> If you can do that sudo, you can also modify the configuration and use
> one of the mount options.
And that's as false as it can be! Ok, no sane admin would probably give
out sudo permissions for cp, but other commands may make sense (perhaps
setting some sysctl in /proc -- that needs fsuid=0 -- otherwise one
could teach sudo to set euid, but not fsuid). And than the user would
*NOT* be able to use those mount options.
Anyway, why are the options not available to non-root? It's their
filesystem, they should be allowed to set it up!
> > > 4) Access should not be further restricted for the owner of the
> > > mount, even if permission bits, uid or gid would suggest
> > > otherwise
> >
> > Similar questions.
>
> This behavior can be disabled by the "default_permissions" mount
> option (wich is not privileged, since it adds restrictions). A FUSE
> filesystem mounted by root (and not for private purposes) would
> normally be done with "allow_other,default_permissions".
I'd hell lot prefer it the other way around. The user write bit is
an accident counter-measure similarly to the root squashing.
It needs to be split to two orthogonal options -- one to specify,
whether all files are owned by the mounter or by whomever the filesystem
says and another whether permissions are checked.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[email protected]>
Jamie Lokier <[email protected]> wrote:
> Miklos Szeredi wrote:
>>???4)?Access?should?not?be?further?restricted?for?the?owner?of?the
>>??????mount,?even?if?permission?bits,?uid?or?gid?would?suggest
>>??????otherwise
>?
>?Why???Surely?you?want?to?prevent?writing?to?files?which?don't?have?the
>?writable?bit?set???A?filesystem?may?also?create?append-only?files?-
>?and?all?users?including?the?mount?owner?should?be?bound?by?that.
That?will?depend?on?the?situation.?If?the?user?is?mounting?a?tgz?owned
by?himself,?FUSE?should?default?to?being?a?convenient?hex-editor.
>>???5)?As?much?of?the?available?information?should?be?exported?via?the
>>??????filesystem?as?possible
>?
>?This?is?the?root?of?the?conflict.??You?are?trying?to?overload?the
>?permission?bits?and?uid/gid?to?mean?something?different?than?they
>?normally?do.
>?
>?While?it's?convenient?to?see?some?"remote"?information?such?as?the
>?uid/gid?in?a?tar?file,?are?you?sure?it's?a?good?idea?to?break?the?unix
>?permissions?model?-?which?will?break?some?programs???(For?example,?try
>?editing?a?file?with?the?broken?semantics?in?an?editor?which?checks?the
>?uid/gid?of?the?file?against?the?current?user).
The?editor?will?try?to?keep?the?original?permissions,?and?saving?will?be
less?effective.
>>???1)?Only?allow?mount?over?a?directory?for?which?the?user?has?write
>>??????access?(and?is?not?sticky)
>?
>?Seems?good?-?but?why?not?sticky???Mounting?a?user?filesystem?in
>?/tmp/user-xxx/my-mount-point?seems?not?unreasonable?-?provided?the
>?administrator?can?delete?the?directory?(which?is?possible?with
>?detachable?mount?points).
I?once?mounted?a?filesystem?in?~/tmp?after?forgetting?about?it?being?a
symlink?to?/tmp/$me/tmp,?and?I?had?to?promise?never?to?do?that?again.
Ng?zvqavtug,?gur?pyrnahc-grzc-fpevcg?xvpxrq?va.
>>???5)?The?filesystem?daemon?is?free?to?fill?in?all?file?attributes?to
>>??????any?(sane)?value,?and?the?kernel?won't?modify?these.
>?
>?Dangerous,?because?an?administrative?program?might?actually?trust?the
>?attributes?to?mean?what?they?normally?mean?in?the?unix?permissions?model.
The?same?risk?applies?to?smbmounted?file?systems.
Sane?daemons?will?do?no?check?besides?matching?the?owner?of?a?file?in?the
user's?home?against?the?expected?UID?and?checking?the?permission?mask,
since?you?can't?trust?users?not?to?mess?with?files?in?directories?they?own.
The?"best"?they?can?do?should?be?shoothing?their?own?feet.
(If?the?user?doesn't?own?the?directory,?FUSE?shouldn't?mount.)
--?
Top?100?things?you?don't?want?the?sysadmin?to?say:
80.?I?cleaned?up?the?root?partition?and?now?there's?LOTS?of?free?space.
Fri?,?Spammer:[email protected][email protected]
Miklos Szeredi wrote:
> > It would also be nice to generalise and have virtual filesystems which
> > are able to present different views to different users. Can FUSE do
> > that already - is the userspace part told which user is doing each
> > operation?
>
> Yes.
>
> > With that, the desire for virtual filesystems which cannot be read
> > by your sysadmin (by accident) is easy to satisfy - and that kind of
> > mechanism would probably be acceptable to all.
>
> The problem is that this way the responsibility goes to the userspace
> program, which can't be trusted.
That does not make sense.
Are you saying you cannot trust your own sshfs userspace daemon?
-- Jamie
Miklos Szeredi wrote:
> The same is true for the case when you mount an sshfs. Since you
> entered your password (or have a passwordless login to the server) you
> are authorized to browse the files on the server, but only with the
> capabilities you have there as a user. The server does the
> authorization. The same is true for an NFS mount btw. It's not the
> client that checks the permissions.
>
> So do you see why I argue in favor of having an option _not_ to check
> permissions on the client by the kernel?
Note that NFS checks the permissions on _both_ the client and server,
for a reason.
-- Jamie
Bodo Eggert <[email protected]> wrote:
> Jamie Lokier <[email protected]> wrote:
> > Miklos Szeredi wrote:
>
> >>???4)?Access?should?not?be?further?restricted?for?the?owner?of?the
> >>??????mount,?even?if?permission?bits,?uid?or?gid?would?suggest
> >>??????otherwise
> >?
> >?Why???Surely?you?want?to?prevent?writing?to?files?which?don't?have?the
> >?writable?bit?set???A?filesystem?may?also?create?append-only?files?-
> >?and?all?users?including?the?mount?owner?should?be?bound?by?that.
>
> That?will?depend?on?the?situation.?If?the?user?is?mounting?a?tgz?owned
> by?himself,?FUSE?should?default?to?being?a?convenient?hex-editor.
If the user wants to edit a read-only file in a tgz owned by himself,
why can he not _chmod_ the file and _then_ edit it?
That said, I would _usually_ prefer that when I enter a tgz, that I
see all component files having the same uid/gid/permissions as the tgz
file itself - the same as I'd see if I entered a zip file.
-- Jamie
Bodo Eggert <[email protected]> wrote:
> >> That is exactly the intended effect. If I'm at my work machine (where
> >> I'm not an admin unfortunately) and I mount my home machine with sshfs
> >> (because FUSE is installed fortunately :), then I bloody well don't
> >> want the sysadmin or some automated script of his to go mucking under
> >> the mountpoint.
> >
> > I think that would be _much_ nicer implemented as a mount which is
> > invisible to other users, rather than one which causes the admin's
> > scripts to spew error messages. Is the namespace mechanism at all
> > suitable for that?
>
> This will require shared subtrees plus a way for new logins from the same
> user to join an existing (previous login) namespace.
Or "per-user namespaces".
It's part of a more general problem of how you limit access to private
data such as crypto keys, either per user, or more finely than that.
Isn't that what all the keyring stuff is for?
-- Jamie
> Note that NFS checks the permissions on _both_ the client and server,
> for a reason.
Does it? If I read the code correctly the client checks credentials
supplied by the server (or cached). But the server does the actual
checking of permissions.
Am I missing something?
Thanks,
Miklos
> > > With that, the desire for virtual filesystems which cannot be read
> > > by your sysadmin (by accident) is easy to satisfy - and that kind of
> > > mechanism would probably be acceptable to all.
> >
> > The problem is that this way the responsibility goes to the userspace
> > program, which can't be trusted.
>
> That does not make sense.
>
> Are you saying you cannot trust your own sshfs userspace daemon?
OK, I was not clear here. When I say it cannot be trusted I'm in my
sysadmin cap, not my user cap.
Hiding the mountpoint from root has dual purpose:
1) Sysadmin won't accidentaly spy on user's private files
2) User can't confuse sysadmin deliberately, by creating a
filesystem containing files he otherwise wouldn't be able to
create
For 1) your porposal makes sense, however for 2) it's useless, since
now the user doesn't want the hiding.
Miklos
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jamie Lokier wrote:
> That does not make sense.
>
> Are you saying you cannot trust your own sshfs userspace daemon?
The user who wrote the userspace code may be able to, but the system
shouldn't trust the userspace daemon. Permissions will be enforced by
the ssh server.
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCW+ZLaI0dwg4A47wRAnDVAKCb2Hk39ouYkjEDgTlz+RTsPsAn5QCgpKvZ
rfYjOi+x6+RSie+t8GIxX74=
=qShM
-----END PGP SIGNATURE-----
> If the user wants to edit a read-only file in a tgz owned by himself,
> why can he not _chmod_ the file and _then_ edit it?
>
> That said, I would _usually_ prefer that when I enter a tgz, that I
> see all component files having the same uid/gid/permissions as the tgz
> file itself - the same as I'd see if I entered a zip file.
I can accept that usually you are not interested in the stored
uid/gid. But doubt that you want to lose permission information when
you mount a tar file. Zip is a different kettle of fish since that
doesn't contain uid/gid/permissions.
Miklos
Frank Sorenson wrote:
> > That does not make sense.
> >
> > Are you saying you cannot trust your own sshfs userspace daemon?
>
> The user who wrote the userspace code may be able to, but the system
> shouldn't trust the userspace daemon. Permissions will be enforced by
> the ssh server.
In fact that's wrong. Although permissions are enforced by the ssh
server, the server assumes that once a conncection is established, all
requests on it are from the same originating user. The server is not
able to check which user is accessing the files on the client machine
- which is why Miklos wants/needs restrictive permissions on the
client machine too.
-- Jamie
> For 1) your porposal makes sense, however for 2) it's useless, since
> now the user doesn't want the hiding.
I realize that the idea _could_ be used to drop 'allow_root' mount
option from the kernel. Since 'allow_root' doesn't add any security
over 'allow_other' it's safe to do it in userspace.
Goodie :)
Thanks,
Miklos
Miklos Szeredi wrote:
> > If the user wants to edit a read-only file in a tgz owned by himself,
> > why can he not _chmod_ the file and _then_ edit it?
> >
> > That said, I would _usually_ prefer that when I enter a tgz, that I
> > see all component files having the same uid/gid/permissions as the tgz
> > file itself - the same as I'd see if I entered a zip file.
>
> I can accept that usually you are not interested in the stored
> uid/gid. But doubt that you want to lose permission information when
> you mount a tar file. Zip is a different kettle of fish since that
> doesn't contain uid/gid/permissions.
It's not about being not interested.
It's because I'd want my programs, and other users, to have exactly
the same access to the tgz contents through vfs as they have when
accessing the tgz file directly. Not some baroque combination of
unobvious hard-coded permission rules, that aren't even visible
through stat(), and which both increase permissions for the user and
decrease it for others at the same time.
I see why you may want to hide certain things from other users
sometimes - the sshfs example is a good one. I daresay Al Viro could
come up with a per-user or per-keyring mount point for those occasions :)
-- Jamie
Miklos Szeredi wrote:
> > Note that NFS checks the permissions on _both_ the client and server,
> > for a reason.
>
> Does it? If I read the code correctly the client checks credentials
> supplied by the server (or cached). But the server does the actual
> checking of permissions.
>
> Am I missing something?
Yes, for NFSv2, this test in nfs_permssion():
if (!NFS_PROTO(inode)->access)
goto out;
And for either version of NFS, if the uid and gid are non-zero, and
the permission bits indicate that an access is permitted, then the
client does not consult the server for permission.
-- Jamie
> > I can accept that usually you are not interested in the stored
> > uid/gid. But doubt that you want to lose permission information when
> > you mount a tar file. Zip is a different kettle of fish since that
> > doesn't contain uid/gid/permissions.
>
> It's not about being not interested.
>
> It's because I'd want my programs, and other users, to have exactly
> the same access to the tgz contents through vfs as they have when
> accessing the tgz file directly.
OK, that makes sense, and it should be an option.
> Not some baroque combination of unobvious hard-coded permission
> rules, that aren't even visible through stat(), and which both
> increase permissions for the user and decrease it for others at the
> same time.
I look at it differently. I want the tar filesystem to be analogous
to running tar. When I run tar, other users are not notified of the
output, it's only for me. If they want to run tar, they can too.
The same can be true for tarfs. I mount it for my purpose, others can
mount it for theirs. Since the daemon providing the filesystem asways
runs with the same capabilities as the user who did the mount, I and
others will always get the permissions that we have on the actual tar
file.
The end result in permission rules is the _same_ as with your
proposal. There's nothing baroque in it.
Think of the "no permission for others" as "hiding", not as some
special permission rule. And if this hiding can be nicely done with
namespaces, all the better, I'll happily drop this feature at that
instant.
> I see why you may want to hide certain things from other users
> sometimes - the sshfs example is a good one. I daresay Al Viro could
> come up with a per-user or per-keyring mount point for those occasions :)
Yeah, maybe that's something worth exploring.
Thanks,
Miklos
On Tue, Apr 12, 2005 at 17:13:03 +0100, Jamie Lokier wrote:
> Miklos Szeredi wrote:
> > > Note that NFS checks the permissions on _both_ the client and server,
> > > for a reason.
> >
> > Does it? If I read the code correctly the client checks credentials
> > supplied by the server (or cached). But the server does the actual
> > checking of permissions.
> >
> > Am I missing something?
>
> Yes, for NFSv2, this test in nfs_permssion():
>
> if (!NFS_PROTO(inode)->access)
> goto out;
>
> And for either version of NFS, if the uid and gid are non-zero, and
> the permission bits indicate that an access is permitted, then the
> client does not consult the server for permission.
... but that clearly says that it checks the permissions on *either*
cleint *or* server. Not all requests are passed to the server and there
the client only checks the permission bits, even if the credentials are
different than what was originally used to obtain the information.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[email protected]>
Miklos Szeredi wrote:
> > Yes, for NFSv2, this test in nfs_permssion():
> >
> > if (!NFS_PROTO(inode)->access)
> > goto out;
>
> I've seen that, I just thought that was for some broken servers not
> for all NFSv2 servers.
>
> Anyway that's been fixed in NFSv3, so obviously the "permission
> checking on both sides" wasn't optimal :)
>
> > And for either version of NFS, if the uid and gid are non-zero, and
> > the permission bits indicate that an access is permitted, then the
> > client does not consult the server for permission.
>
> Where's that? I see no such check.
/*
* Trust UNIX mode bits except:
*
* 1) When override capabilities may have been invoked
* 2) When root squashing may be involved
* 3) When ACLs may overturn a negative answer */
if (!capable(CAP_DAC_OVERRIDE) && !capable(CAP_DAC_READ_SEARCH)
&& (current->fsuid != 0) && (current->fsgid != 0)
&& error != -EACCES)
goto out;
-- Jamie
> >
> > > And for either version of NFS, if the uid and gid are non-zero, and
> > > the permission bits indicate that an access is permitted, then the
> > > client does not consult the server for permission.
> >
> > Where's that? I see no such check.
>
> /*
> * Trust UNIX mode bits except:
> *
> * 1) When override capabilities may have been invoked
> * 2) When root squashing may be involved
> * 3) When ACLs may overturn a negative answer */
> if (!capable(CAP_DAC_OVERRIDE) && !capable(CAP_DAC_READ_SEARCH)
> && (current->fsuid != 0) && (current->fsgid != 0)
> && error != -EACCES)
> goto out;
Still can't find it :)
Which kernel? Which file?
Thanks,
Miklos
> Indeed, if it can be done with namespaces _and_ mounting on a file
> (that file-as-directory concept), _and_ automounting, then you could
> cd into your tgz files and others could too :)
There's still that little problem of accessing the tgz file both as a
file and a directory. But yes. Maybe in 10 years time :)
Miklos
Miklos Szeredi wrote:
> The same can be true for tarfs. I mount it for my purpose, others can
> mount it for theirs. Since the daemon providing the filesystem asways
> runs with the same capabilities as the user who did the mount, I and
> others will always get the permissions that we have on the actual tar
> file.
Fair enough.
> Think of the "no permission for others" as "hiding", not as some
> special permission rule. And if this hiding can be nicely done with
> namespaces, all the better, I'll happily drop this feature at that
> instant.
Indeed, if it can be done with namespaces _and_ mounting on a file
(that file-as-directory concept), _and_ automounting, then you could
cd into your tgz files and others could too :)
-- Jamie
Miklos Szeredi wrote:
> > Indeed, if it can be done with namespaces _and_ mounting on a file
> > (that file-as-directory concept), _and_ automounting, then you could
> > cd into your tgz files and others could too :)
>
> There's still that little problem of accessing the tgz file both as a
> file and a directory. But yes. Maybe in 10 years time :)
There was a thread a few months ago where file-as-directory was
discussed extensively, after Namesys implemented it. That's where the
conversation on detachable mount points originated AFAIR. It will
probably happen at some point.
A nice implemention of it in FUSE could push it along a bit :)
-- Jamie
Miklos Szeredi wrote:
> Still can't find it :)
>
> Which kernel? Which file?
I'm looking at linux-2.4.30/fs/nfs/dir.c.
-- Jamie
> > > Note that NFS checks the permissions on _both_ the client and server,
> > > for a reason.
> >
> > Does it? If I read the code correctly the client checks credentials
> > supplied by the server (or cached). But the server does the actual
> > checking of permissions.
> >
> > Am I missing something?
>
> Yes, for NFSv2, this test in nfs_permssion():
>
> if (!NFS_PROTO(inode)->access)
> goto out;
I've seen that, I just thought that was for some broken servers not
for all NFSv2 servers.
Anyway that's been fixed in NFSv3, so obviously the "permission
checking on both sides" wasn't optimal :)
> And for either version of NFS, if the uid and gid are non-zero, and
> the permission bits indicate that an access is permitted, then the
> client does not consult the server for permission.
Where's that? I see no such check.
Thanks,
Miklos
On Tue, 12 Apr 2005, Jamie Lokier wrote:
> Bodo Eggert <[email protected]> wrote:
> > > I think that would be _much_ nicer implemented as a mount which is
> > > invisible to other users, rather than one which causes the admin's
> > > scripts to spew error messages. Is the namespace mechanism at all
> > > suitable for that?
> >
> > This will require shared subtrees plus a way for new logins from the same
> > user to join an existing (previous login) namespace.
>
> Or "per-user namespaces".
A general way to enter child namespaces would be much more flexible. The
mechanism could be reused by projects like linux-vserver.
--
Our last fight was my fault: My wife asked me "What's on the TV?"
I said, "Dust!"
Anton Altaparmakov wrote:
> > That said, I would _usually_ prefer that when I enter a tgz, that I
> > see all component files having the same uid/gid/permissions as the tgz
> > file itself - the same as I'd see if I entered a zip file.
>
> As you say _usually_, even you admit that sometimes you would want the
> real owner/permissions to be shown. And that is the point Miklos is
> trying to make I believe: it should be configurable not hard set to only
> one which is what I understand HCH wants.
>
> There are uses for both. For example today I was updating the tar ball
> which is used to create the var file system for a new chroot. I certainly
> want to see corretly setup owner/permissions when I look into that tar
> ball using a FUSE fs...
If I'm updating a var filesystem for a new chroot, I'd need the
ability to chmod and chown things in that filesystem. Does that work
as an ordinary user?
-- Jamie
> There was a thread a few months ago where file-as-directory was
> discussed extensively, after Namesys implemented it. That's where the
> conversation on detachable mount points originated AFAIR. It will
> probably happen at some point.
>
> A nice implemention of it in FUSE could push it along a bit :)
Aren't there some assumptions in VFS that currently make this
impossible?
I'll go and find that thread.
Thanks,
Miklos
> > Still can't find it :)
> >
> > Which kernel? Which file?
>
> I'm looking at linux-2.4.30/fs/nfs/dir.c.
Ahh, OK.
nfs_permission() in 2.6 looks quite a bit different. And permission
bits are not used if ->access() is available.
Miklos
On Mon, 11 Apr 2005, Jamie Lokier wrote:
> Miklos Szeredi wrote:
> > That is exactly the intended effect. If I'm at my work machine (where
> > I'm not an admin unfortunately) and I mount my home machine with sshfs
> > (because FUSE is installed fortunately :), then I bloody well don't
> > want the sysadmin or some automated script of his to go mucking under
> > the mountpoint.
>
> I think that would be _much_ nicer implemented as a mount which is
> invisible to other users, rather than one which causes the admin's
> scripts to spew error messages. Is the namespace mechanism at all
> suitable for that?
>
> It would also be nice to generalise and have virtual filesystems which
> are able to present different views to different users. Can FUSE do
> that already - is the userspace part told which user is doing each
> operation? With that, the desire for virtual filesystems which cannot
> be read by your sysadmin (by accident) is easy to satisfy - and that
> kind of mechanism would probably be acceptable to all.
Yes it does. We use it to provide magic symlinks which point to different
places for different people. So we have for example a symlink called "ux"
and it points to "/servers/USERNAME/our-server/ux" where USERNAME is the
name from /etc/passwd matching the user id of the user accessing the
symlink. So in documentaion and in stupid programs which require
hardcoding of path we specify "/ux" to find the shared space but in
reality this is a different local directory for every user. (To complete
the picture the different local directories are actually the same remote
directory but mounted with access permissions for each user separately
using ncpfs.)
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
On Tue, 12 Apr 2005, Jamie Lokier wrote:
> Bodo Eggert <[email protected]> wrote:
> > Jamie Lokier <[email protected]> wrote:
> > > Miklos Szeredi wrote:
> >
> > >>???4)?Access?should?not?be?further?restricted?for?the?owner?of?the
> > >>??????mount,?even?if?permission?bits,?uid?or?gid?would?suggest
> > >>??????otherwise
> > >?
> > >?Why???Surely?you?want?to?prevent?writing?to?files?which?don't?have?the
> > >?writable?bit?set???A?filesystem?may?also?create?append-only?files?-
> > >?and?all?users?including?the?mount?owner?should?be?bound?by?that.
> >
> > That?will?depend?on?the?situation.?If?the?user?is?mounting?a?tgz?owned
> > by?himself,?FUSE?should?default?to?being?a?convenient?hex-editor.
>
> If the user wants to edit a read-only file in a tgz owned by himself,
> why can he not _chmod_ the file and _then_ edit it?
>
> That said, I would _usually_ prefer that when I enter a tgz, that I
> see all component files having the same uid/gid/permissions as the tgz
> file itself - the same as I'd see if I entered a zip file.
As you say _usually_, even you admit that sometimes you would want the
real owner/permissions to be shown. And that is the point Miklos is
trying to make I believe: it should be configurable not hard set to only
one which is what I understand HCH wants.
There are uses for both. For example today I was updating the tar ball
which is used to create the var file system for a new chroot. I certainly
want to see corretly setup owner/permissions when I look into that tar
ball using a FUSE fs...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
> > There are uses for both. For example today I was updating the tar ball
> > which is used to create the var file system for a new chroot. I certainly
> > want to see corretly setup owner/permissions when I look into that tar
> > ball using a FUSE fs...
>
> If I'm updating a var filesystem for a new chroot, I'd need the
> ability to chmod and chown things in that filesystem. Does that work
> as an ordinary user?
Yes, within UML for example.
I have a little project to imlement a "userloop" filesystem, which
works just like "mount -o loop", but you don't need root privs. This
is really simple to do with FUSE and UML.
I don't think that it's far feched, that in certain situations the
user _does_ have the right (and usefulness) to do otherwise privileged
filesystem operations.
Miklos
On Tue, Apr 12, 2005 at 21:08:25 +0200, Miklos Szeredi wrote:
> > There was a thread a few months ago where file-as-directory was
> > discussed extensively, after Namesys implemented it. That's where the
> > conversation on detachable mount points originated AFAIR. It will
> > probably happen at some point.
> >
> > A nice implemention of it in FUSE could push it along a bit :)
>
> Aren't there some assumptions in VFS that currently make this
> impossible?
I believe it's OK with VFS, but applications would be confused to death.
Well, there really is one issue -- dentries have exactly one parent, so
what do you do when opening a file with hardlinks as a directory? (In
fact IIRC that is what lead to all the funny talk about mountpoints,
since they don't have this limitation)
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[email protected]>
On Wed, Apr 13, 2005 at 11:14:10 +0200, Miklos Szeredi wrote:
> > > There are uses for both. For example today I was updating the tar ball
> > > which is used to create the var file system for a new chroot. I certainly
> > > want to see corretly setup owner/permissions when I look into that tar
> > > ball using a FUSE fs...
> >
> > If I'm updating a var filesystem for a new chroot, I'd need the
> > ability to chmod and chown things in that filesystem. Does that work
> > as an ordinary user?
>
> Yes, within UML for example.
That's a bad example. UML does in fact *NOT* invoke host kernel's chmod,
because it has all the filesystem in a file.
But the answer is yes anyway. It's up to the filesystem to check whether
it is allowed. FUSE does not block it and if the actual userland driver
does not protest either, it is possible.
>[...]
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[email protected]>
> > Aren't there some assumptions in VFS that currently make this
> > impossible?
>
> I believe it's OK with VFS, but applications would be confused to death.
> Well, there really is one issue -- dentries have exactly one parent, so
> what do you do when opening a file with hardlinks as a directory? (In
> fact IIRC that is what lead to all the funny talk about mountpoints,
> since they don't have this limitation)
OK, that makes sense.
It would be quite interesting to see how applications react. Maybe
I'll hack something up :)
Thanks,
Miklos
> > > A nice implemention of it in FUSE could push it along a bit :)
> >
> > Aren't there some assumptions in VFS that currently make this
> > impossible?
>
> I believe it's OK with VFS, but applications would be confused to death.
> Well, there really is one issue -- dentries have exactly one parent, so
> what do you do when opening a file with hardlinks as a directory? (In
> fact IIRC that is what lead to all the funny talk about mountpoints,
> since they don't have this limitation)
Hardlinks aren't a problem when entering a file as if it's a
directory, provided the directory does not contain any hard links to a
parent in the hierarchy. In other words, as long as it's a directed
acyclic graph.
This is trivially always true for virtual directories such as entering
an archive file. And detachable/movable mountpoints are a nice and
sensible way to implement it. Some work has actually been done on this.
Experiments with the reiserfs file-as-directory extension showed that
applications are generally ok with it. It looks like a file, but you
can cd into it or follow a path lookup into it.
Linus had some good ideas on the exact semantics to implement when
doing path lookup on these objects.
-- Jamie
Miklos Szeredi wrote:
> > > Aren't there some assumptions in VFS that currently make this
> > > impossible?
> >
> > I believe it's OK with VFS, but applications would be confused to death.
> > Well, there really is one issue -- dentries have exactly one parent, so
> > what do you do when opening a file with hardlinks as a directory? (In
> > fact IIRC that is what lead to all the funny talk about mountpoints,
> > since they don't have this limitation)
>
> OK, that makes sense.
>
> It would be quite interesting to see how applications react. Maybe
> I'll hack something up :)
Look up the rather large linux-kernel & linux-fsdevel thread "silent
semantic changes with reiser4" and it's followup threads, from last
year.
It's already been tried. You will also find sensible ideas on what
semantics it should have to do it properly.
-- Jamie
> Look up the rather large linux-kernel & linux-fsdevel thread "silent
> semantic changes with reiser4" and it's followup threads, from last
> year.
Wow, it's 700+ messages. I got through the first 40, and already feel
dizzy :)
> It's already been tried. You will also find sensible ideas on what
> semantics it should have to do it properly.
OK, I understand the "slash -> directory, no-slash -> regular file"
semantics.
How do you envision implementing this for "mount directory over file"?
A new mount flag indicating that it's only to be followed down if
there's a slash after the mountpoint?
Thanks,
Miklos
Miklos Szeredi wrote:
> > Look up the rather large linux-kernel & linux-fsdevel thread "silent
> > semantic changes with reiser4" and it's followup threads, from last
> > year.
>
> Wow, it's 700+ messages. I got through the first 40, and already feel
> dizzy :)
It's easier if you skip the ones by Hans and their immediate followups :)
(Nothing personal, it's that Hans is mostly justifying reiser4's
behaviour, and the posts you really need to read aren't about reiser4).
> > It's already been tried. You will also find sensible ideas on what
> > semantics it should have to do it properly.
>
> OK, I understand the "slash -> directory, no-slash -> regular file"
> semantics.
>
> How do you envision implementing this for "mount directory over file"?
Somewhere deep in that thread is a discussion between Al Viro and
Linus on it.
> A new mount flag indicating that it's only to be followed down if
> there's a slash after the mountpoint?
The new flag would indicate more than that: These mounts should be
detachable in the sense that deleting the file is possible, and
perhaps renamable/linkable too. That's the stuff Al Viro discusses in
some detail in the big thread.
Ideally we'd like automounting, a bit like the Hurd's translators.
Attached to files (using an xattr or something, and executed with the
uid/gid of the file owner), and also per-user "pattern->action"
options for matching files with a certain type (e.g. tgz/zip/deb/rpm/xml).
But that can be added much later, as it's an orthogonal feature.
-- Jamie
Miklos Szeredi wrote:
> I have a little project to imlement a "userloop" filesystem, which
> works just like "mount -o loop", but you don't need root privs. This
> is really simple to do with FUSE and UML.
That would be a nice way to implement those rarely used old
filesystems that aren't really needed in the kernel source tree any
more, but which it would be nice to have access to as legacy
filesystem formats.
In other words, migrating old legacy filesystems out of the kernel
tree, into FUSE.
> I don't think that it's far feched, that in certain situations the
> user _does_ have the right (and usefulness) to do otherwise privileged
> filesystem operations.
It's really a matter of philosophy, as to whether the results of
stat() are just handy information for the user, or are always defined
to mean what you can/can't do with a file.
Local-ssh-into-UML makes more sense for this in some ways, because the
uids/gids inside your tgz files or foreign loop filesystems are not
related to the space of uids/gids of the host system. Yet, the
results from stat() don't distinguish the number spaces, and "ls"
doesn't map the numbers to names properly in the wrong space.
-- Jamie
> > I have a little project to imlement a "userloop" filesystem, which
> > works just like "mount -o loop", but you don't need root privs. This
> > is really simple to do with FUSE and UML.
>
> That would be a nice way to implement those rarely used old
> filesystems that aren't really needed in the kernel source tree any
> more, but which it would be nice to have access to as legacy
> filesystem formats.
>
> In other words, migrating old legacy filesystems out of the kernel
> tree, into FUSE.
Not much migration would be needed other than deleting from the
current kernel. As long as the lagacy filesystem exists in a kernel
that has UML support it should just work.
> > I don't think that it's far feched, that in certain situations the
> > user _does_ have the right (and usefulness) to do otherwise privileged
> > filesystem operations.
>
> It's really a matter of philosophy, as to whether the results of
> stat() are just handy information for the user, or are always defined
> to mean what you can/can't do with a file.
Yes, this is the very heart of the conflict between my and your
(Christoph's, etc) view.
I argue for more flexibilty, i.e. less policy in kernel, which is a
good thing generally.
As long as it's secure, what is the problem with it? If users are
confused, then they will chose the strict mode. If somebody would
like to see more information in the filesystem, they use the relaxed
mode.
The key here is security IMO. So if you find a security problem with
the relaxed mode (together with "hiding") then I bow my head.
Otherwise who cares if it confuses applications (haven't met any) or
users. It doensn't matter. If it confuses anything or anyone, the
filesystem writer can fix it.
> Local-ssh-into-UML makes more sense for this in some ways, because the
> uids/gids inside your tgz files or foreign loop filesystems are not
> related to the space of uids/gids of the host system.
Ssh into UML is awkward, because you don't necessary have all the
tools installed, have networking, etc. And in UML the uid/gid won't
make any more sense either.
> Yet, the results from stat() don't distinguish the number spaces,
> and "ls" doesn't map the numbers to names properly in the wrong
> space.
Well you can use "ls -n". It's up to the tools to present the
information you want in the way you want it. If a tool can't do that,
tough, but you are not worse off than if the information is not
available _at_all_.
Thanks,
Miklos
Miklos Szeredi wrote:
> > Yet, the results from stat() don't distinguish the number spaces,
> > and "ls" doesn't map the numbers to names properly in the wrong
> > space.
>
> Well you can use "ls -n". It's up to the tools to present the
> information you want in the way you want it. If a tool can't do that,
> tough, but you are not worse off than if the information is not
> available _at_all_.
Well, how do you currently provide access to the information that's
not presentable through stat()?
-- Jamie
> > > Yet, the results from stat() don't distinguish the number spaces,
> > > and "ls" doesn't map the numbers to names properly in the wrong
> > > space.
> >
> > Well you can use "ls -n". It's up to the tools to present the
> > information you want in the way you want it. If a tool can't do that,
> > tough, but you are not worse off than if the information is not
> > available _at_all_.
>
> Well, how do you currently provide access to the information that's
> not presentable through stat()?
Obviously I don't. However that's hardly an argument for providing
even less information.
And stat() btw pretty much covers what information there is to present
for network filesystems and archives, since there _is_ a real
filesystem where the information originated from (though sometimes
it's not a UNIX type of filesystem, in which case there has to be some
mapping of the info).
Miklos
On 4/12/05, Miklos Szeredi <[email protected]> wrote:
> > I think that would be _much_ nicer implemented as a mount which is
> > invisible to other users, rather than one which causes the admin's
> > scripts to spew error messages.
>>
> > Is the namespace mechanism at all suitable for that?
>
> It is certainly the right tool for this. However currently private
> namespaces are quite limited. The only sane usage I can think of is
> that before mounting the user starts a shell with CLONE_NS, and does
> the mount in this. However all the other programs he already has
> running (editor, browser, desktop environment) won't be able to access
> the mount.
>
I'd like to second that I think private-namespaces are the right way
to solve this sort of problem. It also helps not cluttering the
global namespace with user-local mounts
>
> Shared subtrees and more support in userspace tools is needed before
> private namespaces can become really useful.
>
I'd like to talk about this a bit more and start driving to a solution
here. I've been looking at the namespace code quite a bit and was
just about to dive in and start checking into adding/fixing certain
aspects such as stackable namespaces, optional inheritence (changes in
a parent namespace are reflected in the child but not vice-versa),
etc.
One aspect I was thinking about here was a mount flag that would give
you a new private namespace (if you didn't already have one) for the
mount (and I guess that would impact any subsequent mounts from the
user in that shell). Another option would be a 'newns' style
system-call, but I'm generally against adding new system calls.
Shared subtrees are a tricky one. I know how we would handle it in
V9FS, but not sure how well that would translate to others
(essentially we'd re-export the subtree so other user's could mount it
individually -- but that's a very Plan 9 solution and may not be what
more UNIX-minded folks would want -- we also need to improve our own
server infrastructure to more efficiently support such a re-export).
So, to sum up I think private namespaces is the right solution, and
I'd rather put effort into making it more useful than work-around the
fact that its not practical right now.
-eric
On 4/11/05, Miklos Szeredi <[email protected]> wrote:
>
> 1) Only allow mount over a directory for which the user has write
> access (and is not sticky)
>
> 2) Use nosuid,nodev mount options
>
> [ parts deleted ]
Do these solve all the security concerns with unprivileged mounts, or
are there other barriers/concerns? Should there be ulimit (or rlimit)
style restrictions on how many mounts/binds a user is allowed to have
to prevent users from abusing mount privs?
I was thinking about this a while back and thought having a user-mount
permissions file might be the right way to address lots of these
issues. Essentially it would contain information about what
users/groups were allowed to mount what sources to what destinations
and with what mandatory options.
You can get the start of this with the user/users/etc. stuff in
/etc/fstab, but I was envisioning something a bit more dynamic with
regular expression based rules for sources and destinations. So,
something like:
# /etc/usermounts: user mount permissions
# <fs> <mount point> <type> <opts>
# allow users to mount any file system under their home directory
* $HOME *
nosuid, nosgid
# allow users to bind over /usr/bin as long as its only in their
private namespace
* /usr/bin
bind newns
# allow users to loopback mount distributed file systems to /mnt
127.0.0.1 /mnt *
nosuid, nosgid
# allow users to mount files over any directory they have right access to
* (perm=0222) *
nosuid, nosgid
Is this unnecessary? Is this not enough?
-eric
Eric Van Hensbergen wrote:
> I'd like to second that I think private-namespaces are the right way
> to solve this sort of problem. It also helps not cluttering the
> global namespace with user-local mounts
>
> >
> > Shared subtrees and more support in userspace tools is needed before
> > private namespaces can become really useful.
> >
>
> I'd like to talk about this a bit more and start driving to a solution
> here. I've been looking at the namespace code quite a bit and was
> just about to dive in and start checking into adding/fixing certain
> aspects such as stackable namespaces, optional inheritence (changes in
> a parent namespace are reflected in the child but not vice-versa),
> etc.
>
> One aspect I was thinking about here was a mount flag that would give
> you a new private namespace (if you didn't already have one) for the
> mount (and I guess that would impact any subsequent mounts from the
> user in that shell). Another option would be a 'newns' style
> system-call, but I'm generally against adding new system calls.
>
> Shared subtrees are a tricky one. I know how we would handle it in
> V9FS, but not sure how well that would translate to others
> (essentially we'd re-export the subtree so other user's could mount it
> individually -- but that's a very Plan 9 solution and may not be what
> more UNIX-minded folks would want -- we also need to improve our own
> server infrastructure to more efficiently support such a re-export).
>
> So, to sum up I think private namespaces is the right solution, and
> I'd rather put effort into making it more useful than work-around the
> fact that its not practical right now.
Have a chat with Al Viro, who has already done some work on shared
mounts and subtrees I think.
-- Jamie
> >
> > 1) Only allow mount over a directory for which the user has write
> > access (and is not sticky)
> >
> > 2) Use nosuid,nodev mount options
> >
> > [ parts deleted ]
>
> Do these solve all the security concerns with unprivileged mounts, or
> are there other barriers/concerns? Should there be ulimit (or rlimit)
> style restrictions on how many mounts/binds a user is allowed to have
> to prevent users from abusing mount privs?
Currently there is a (configurable) global limit for all non-root FUSE
mounts. An additional per-user limit would be nice, but from the
security standpoint it doesn't matter.
> I was thinking about this a while back and thought having a user-mount
> permissions file might be the right way to address lots of these
> issues. Essentially it would contain information about what
> users/groups were allowed to mount what sources to what destinations
> and with what mandatory options.
I haven't yet seen the need for such a great flexibility. Debian
installs fusermount (the FUSE mount utility) "-rwsr-x--- root fuse",
so only users in the "fuse" group are allowed to use it. This is sane
for a new technology, but I expect these limitations to be removed
once it establishes itsef as a secure solution.
> You can get the start of this with the user/users/etc. stuff in
> /etc/fstab, but I was envisioning something a bit more dynamic with
> regular expression based rules for sources and destinations. So,
> something like:
[snip]
> Is this unnecessary? Is this not enough?
Maybe it is necessary, but why bother until somebody actually wants
it? I'm a great believer of the "lazy" development philosophy ;)
Thanks,
Miklos
On 4/17/05, Miklos Szeredi <[email protected]> wrote:
> > >
> > > 1) Only allow mount over a directory for which the user has write
> > > access (and is not sticky)
> > >
> > > 2) Use nosuid,nodev mount options
> > >
> > > [ parts deleted ]
> >
> > Do these solve all the security concerns with unprivileged mounts, or
> > are there other barriers/concerns? Should there be ulimit (or rlimit)
> > style restrictions on how many mounts/binds a user is allowed to have
> > to prevent users from abusing mount privs?
>
> Currently there is a (configurable) global limit for all non-root FUSE
> mounts. An additional per-user limit would be nice, but from the
> security standpoint it doesn't matter.
>
> > I was thinking about this a while back and thought having a user-mount
> > permissions file might be the right way to address lots of these
> > issues. Essentially it would contain information about what
> > users/groups were allowed to mount what sources to what destinations
> > and with what mandatory options.
>
> I haven't yet seen the need for such a great flexibility. Debian
> installs fusermount (the FUSE mount utility) "-rwsr-x--- root fuse",
These are both well and good, but I was looking for a more global
system (for things other than FUSE).
>
> > Is this unnecessary? Is this not enough?
>
> Maybe it is necessary, but why bother until somebody actually wants
> it? I'm a great believer of the "lazy" development philosophy ;)
>
Yeah, I guess I'm motivated in that I want to use normal mount to
handle v9fs user file systems, local private mounts, and local private
resource shares. I'd also like normal users to be able to take better
advantage of -o bind. I think its kinda silly that we have special
purpose mounts for cifs, samba, fuse, v9fs, etc -- but I suppose
that's more of a user-space util-linux dilemma than a kernel dilemma.
-eric
Eric Van Hensbergen <[email protected]> wrote:
> On 4/11/05, Miklos Szeredi <[email protected]> wrote:
>>
>> 1) Only allow mount over a directory for which the user has write
>> access (and is not sticky)
>>
>> 2) Use nosuid,nodev mount options
[...]
> Do these solve all the security concerns with unprivileged mounts, or
> are there other barriers/concerns? Should there be ulimit (or rlimit)
> style restrictions on how many mounts/binds a user is allowed to have
> to prevent users from abusing mount privs?
Definitively. Mountpoints use kernel space, the users could DoS the machine.
The per-Machine-limit isn't fine-grained enough, since the users may DoS
each other.
You'll have to avoid users capturing system daemons in D state or in
slowed-down artificial directory-forests, too. I think namespaces will
do most the trick.
> I was thinking about this a while back and thought having a user-mount
> permissions file might be the right way to address lots of these
> issues. Essentially it would contain information about what
> users/groups were allowed to mount what sources to what destinations
> and with what mandatory options.
Users being able to mount random fs containing suid or device nodes
are root whenever they want to. If you want to mount with dev or suid,
use sudo and restrict the mount to a limited set of images/devices/whatever.
--
Anger, fear, aggression. The Dark Side of the Force are they.
Once you start down the Dark Path, forever will it dominate your destiny.
-- Jedi Master Yoda
On 4/17/05, Bodo Eggert <[email protected]>
<[email protected]> wrote:
>
> > I was thinking about this a while back and thought having a user-mount
> > permissions file might be the right way to address lots of these
> > issues. Essentially it would contain information about what
> > users/groups were allowed to mount what sources to what destinations
> > and with what mandatory options.
>
> Users being able to mount random fs containing suid or device nodes
> are root whenever they want to. If you want to mount with dev or suid,
> use sudo and restrict the mount to a limited set of images/devices/whatever.
>
Well, that would kinda be the intent behind the permissions file --
it can specify what restricted set of images/devices/whatever the user
can mount, I suppose the sensible thing would be to always enforce
nosuid and nsgid, but I'd rather keep these as the default version of
options (allowing admins to shoot themselves in the foot perhaps, but
in the single-user workstation case, is seems like there's less reason
to be so paranoid).
-eric
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
> On 4/17/05, Bodo Eggert <[email protected]>
> > > I was thinking about this a while back and thought having a user-mount
> > > permissions file might be the right way to address lots of these
> > > issues. Essentially it would contain information about what
> > > users/groups were allowed to mount what sources to what destinations
> > > and with what mandatory options.
> >
> > Users being able to mount random fs containing suid or device nodes
> > are root whenever they want to. If you want to mount with dev or suid,
> > use sudo and restrict the mount to a limited set of images/devices/whatever.
>
> Well, that would kinda be the intent behind the permissions file --
> it can specify what restricted set of images/devices/whatever the user
> can mount, I suppose the sensible thing would be to always enforce
> nosuid and nsgid, but I'd rather keep these as the default version of
> options (allowing admins to shoot themselves in the foot perhaps, but
> in the single-user workstation case, is seems like there's less reason
> to be so paranoid).
I think you shouldn't help the admins by creating shoes with target marks.
Allowing user mounts with no* should be allways ok (no config needed
besides the ulimit), and mounting specified files to defined locations
is allready supported by fstab.
--
Top 100 things you don't want the sysadmin to say:
6. We prefer not to change the root password, it's an nice easy one
>
> I think you shouldn't help the admins by creating shoes with target marks.
>
> Allowing user mounts with no* should be allways ok (no config needed
> besides the ulimit), and mounting specified files to defined locations
> is allready supported by fstab.
I tend to agree. It should be obvious which sort of mounts are safe
and which are not. The exceptions can go into fstab.
In a private namespace environment bind mounts (nodev,nosuid) should
be OK. Network filesystems (with limitations to the ports used) are
also. Disk filesystems are usually not safe to mount for users,
because they are not tested and verified against untrusted source.
Miklos
On 4/19/05, Bodo Eggert <[email protected]> wrote:
> >
> > Well, that would kinda be the intent behind the permissions file --
> > it can specify what restricted set of images/devices/whatever the user
> > can mount, I suppose the sensible thing would be to always enforce
> > nosuid and nsgid, but I'd rather keep these as the default version of
> > options (allowing admins to shoot themselves in the foot perhaps, but
> > in the single-user workstation case, is seems like there's less reason
> > to be so paranoid).
>
> I think you shouldn't help the admins by creating shoes with target marks.
>
Fair enough. Since I don't really have any cases I can think of that
require this sort of behavior, I'll back off on allowing user mounts
with suid or sgid enabled.
>
> Allowing user mounts with no* should be allways ok (no config needed
> besides the ulimit), and mounting specified files to defined locations
> is allready supported by fstab.
>
Do folks think that the limits should be per-user or per-process for
user-mounts, what about separate limits for # of private namespaces
and # of mounts?
The fstab support doesn't seem to provide enough flexibility for
certain situations, say I want to support mounting any remote file
system, as long as its in the user's private hierarchy? What if I
want user's to be able to mount FUSE, v9fs, etc. user-space file
systems, but only in a private namespace and only in their private
hierarchy? Or are these situations which you think should "always be
okay" as long as nosuid and nogid (and newns?) are implicit?
-eric
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
> On 4/19/05, Bodo Eggert <[email protected]> wrote:
> > Allowing user mounts with no* should be allways ok (no config needed
> > besides the ulimit), and mounting specified files to defined locations
> > is allready supported by fstab.
> >
>
> Do folks think that the limits should be per-user or per-process for
> user-mounts, what about separate limits for # of private namespaces
> and # of mounts?
Per-user.
> The fstab support doesn't seem to provide enough flexibility for
> certain situations, say I want to support mounting any remote file
> system, as long as its in the user's private hierarchy?
[...]
The dir is owned by the user, therefore it's allowed with no*.
--
Top 100 things you don't want the sysadmin to say:
11. Can you get VMS for this Sparc thingy?
Somewhat related question for Viro/the group:
Why is CLONE_NEWNS considered a priveledged operation? Would placing
limits on the number of private namespaces a user can own solve any
resource concerns or is there something more nefarious I'm missing?
Eric Van Hensbergen wrote:
> Somewhat related question for Viro/the group:
>
> Why is CLONE_NEWNS considered a priveledged operation? Would placing
> limits on the number of private namespaces a user can own solve any
> resource concerns or is there something more nefarious I'm missing?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Likely because its a chroot vulnerability.
It allows a process to obtain a reference to the root vfsmount that
doesn't have chroot checks performed on it.
Consider the following pseudo example:
main():
chdir("/");
fd = open(".", O_RDONLY);
clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
cloned_func:
fchdir(fd);
chdir("..");
if main is run within a chroot where it's "/" is on the same vfsmount as
it's "..", then the application can step out of the chroot using clone(2).
Note: using chdir in a vfsmount outside of your namespace works, however
you won't be able to walk off that vfsmount (to its parent or children).
Mike Waychison
> Likely because its a chroot vulnerability.
>
> It allows a process to obtain a reference to the root vfsmount that
> doesn't have chroot checks performed on it.
>
> Consider the following pseudo example:
>
[...]
>
> if main is run within a chroot where it's "/" is on the same vfsmount as
> it's "..", then the application can step out of the chroot using clone(2).
>
> Note: using chdir in a vfsmount outside of your namespace works, however
> you won't be able to walk off that vfsmount (to its parent or children).
How about fixing fchdir, so it checks whether you gone outside the
tree under current->fs->rootmnt? Should be fairly easy to do.
Miklos
Mike Waychison <[email protected]> wrote:
> Consider the following pseudo example:
>
> main():
> chdir("/");
> fd = open(".", O_RDONLY);
> clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
>
> cloned_func:
> fchdir(fd);
> chdir("..");
>
> if main is run within a chroot where it's "/" is on the same vfsmount as
> it's "..", then the application can step out of the chroot using clone(2).
>
> Note: using chdir in a vfsmount outside of your namespace works, however
> you won't be able to walk off that vfsmount (to its parent or children).
IMO the '..' file descriptor should be attached to it's chroot domain.
This should avoid all chroot-escapes, even with fd-passing etc.
I wonder why nobody thought of that. Either it's too obvious or too stupid.
--
Funny quotes:
7. You have the right to remain silent. Anything you say will be misquoted,
then used against you.