All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank van Maarseveen <frankvm@frankvm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: frankvm@frankvm.com, akpm@osdl.org, aia21@cam.ac.uk,
	arjan@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: FUSE merging?
Date: Fri, 1 Jul 2005 14:00:28 +0200	[thread overview]
Message-ID: <20050701120028.GB5218@janus> (raw)
In-Reply-To: <E1DoIjd-0002bM-00@dorka.pomaz.szeredi.hu>

On Fri, Jul 01, 2005 at 12:27:01PM +0200, Miklos Szeredi wrote:
> 
> You mean suid programs are never to touch paths passed to them?

never when euid==root.
The pathname could even point into /proc or anything else yet unknown,
e.g. by putting some symlinks at the right places. The mere act of
opening the file as root could have unwanted side effects already.

> 
> If that would be true, then fuse_allow_task() would not be needed, but
> would do no harm either, since it would never be invoked by a suid
> program.

In theory it should not be necessary. But on a practical side: we need
to provide security for daemons with elevated privileges which need to
traverse all local disks.

> You didn't consider the information leak aspect (point B in fuse.txt).

Correct. I have no answer to that other than: is it a real problem or
yet something else a setuid program should take into consideration?
And what info can we extract already using inotify/dnotify? There are
several ways to monitor activity and it is all information. /proc (ps)
gives information too.

> > -	Forbid hiding data by mounting a FUSE filesystem on top of it (does
> > 	FUSE check for this already?)
> 
> Yes.  It checks for writablilty on the mountpoing (excluding limited
> writablilty as /tmp for example).

But can you mount FUSE on top of a populated tree, a non-leaf dir?

> > -	/proc isn't a problem: most root processes tend to avoid it because
> > 	it is synthetic and thus uninteresting. Maybe we should extend
> > 	the idea of "synthetic file-systems being uninteresting" to any
> > 	process which cannot receive signals from the FUSE mount owner. When
> > 	one cannot hide data by a FUSE mount and its synthetic anyway so not
> > 	interesting then just show the original empty mount point.
> 
> Been there.  People (like Al Viro) didn't like it.

including changing the ptraceability test by a signal test and including
the (IMHO) required emptyness of the mount stub?

Traversing a FUSE mountpoint is almost equivalent to talking with a
userspace program. Why should that be interesting when one simply wants
to traverse the FS? root isn't going to execute all user programs to
see what they do either.

-- 
Frank

  reply	other threads:[~2005-07-01 12:00 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-30  9:19 FUSE merging? Miklos Szeredi
2005-06-30  9:27 ` Andrew Morton
2005-06-30  9:51   ` Miklos Szeredi
2005-06-30 10:00     ` Arjan van de Ven
2005-06-30 10:12       ` Miklos Szeredi
2005-06-30 10:20         ` Arjan van de Ven
2005-06-30 10:24           ` Miklos Szeredi
2005-06-30 19:39             ` Avuton Olrich
2005-07-01  6:23               ` Miklos Szeredi
2005-06-30 11:13           ` Anton Altaparmakov
2005-06-30 19:46             ` Andrew Morton
2005-06-30 20:00               ` Andrew Morton
2005-07-01  6:40                 ` Miklos Szeredi
2005-06-30 22:28               ` Frank van Maarseveen
2005-07-01  6:58                 ` Miklos Szeredi
2005-07-01  9:24                   ` Frank van Maarseveen
2005-07-01 10:27                     ` Miklos Szeredi
2005-07-01 12:00                       ` Frank van Maarseveen [this message]
2005-07-01 12:36                         ` Miklos Szeredi
2005-07-01 13:05                           ` Frank van Maarseveen
2005-07-01 13:21                             ` Miklos Szeredi
2005-07-01 15:20                               ` Frank van Maarseveen
2005-07-01 17:04                                 ` Miklos Szeredi
2005-07-01 18:04                                   ` Frank van Maarseveen
2005-07-01 19:35                                     ` Jeremy Maitin-Shepard
2005-07-02 14:49                                     ` Miklos Szeredi
2005-07-02 16:00                                       ` Frank van Maarseveen
2005-07-03  6:16                                         ` Miklos Szeredi
2005-07-03 11:25                                           ` Frank van Maarseveen
2005-07-03 13:24                                             ` Miklos Szeredi
2005-07-03 13:50                                               ` Frank van Maarseveen
2005-07-03 14:03                                                 ` Miklos Szeredi
2005-07-03 14:10                                               ` FUSE merging? (2) Frank van Maarseveen
2005-07-03 15:47                                                 ` Miklos Szeredi
2005-07-03 19:36                                                   ` Frank van Maarseveen
2005-07-04  8:56                                                     ` Miklos Szeredi
2005-07-04  9:59                                                       ` Frank van Maarseveen
2005-07-04 10:27                                                         ` Miklos Szeredi
2005-07-04 11:26                                                           ` Frank van Maarseveen
2005-07-01  6:36               ` FUSE merging? Miklos Szeredi
2005-07-01  6:50                 ` Andrew Morton
2005-07-01  7:07                   ` Miklos Szeredi
2005-07-01  7:14                     ` Andrew Morton
2005-07-01  7:27                       ` Miles Bader
2005-07-01  7:38                       ` Miklos Szeredi
2005-07-01  8:02                         ` Andrew Morton
2005-07-01 10:11                           ` Miklos Szeredi
2005-07-01 11:29                             ` Andrew Morton
2005-07-01 12:00                               ` Miklos Szeredi
2005-07-01 12:53                               ` Anton Altaparmakov
2005-07-01 13:07                                 ` Anton Altaparmakov
2005-07-01 13:51                                 ` Frank van Maarseveen
2005-07-01 13:29                               ` Eric Van Hensbergen
2005-07-01 16:45                               ` Matthias Urlichs
2005-07-01 12:08                             ` Frank van Maarseveen
2005-07-01 13:21                             ` Eric Van Hensbergen
2005-07-01 13:53                               ` Miklos Szeredi
2005-07-01 14:18                                 ` Eric Van Hensbergen
2005-07-01 14:31                                   ` Miklos Szeredi
2005-07-02 10:01                                     ` Eric W. Biederman
2005-07-02 14:58                                       ` Miklos Szeredi
2005-07-02 16:43                                       ` Eric Van Hensbergen
2005-07-02 17:33                                         ` Eric W. Biederman
2005-07-03 19:39                           ` Pavel Machek
2005-07-04  8:38                             ` Miklos Szeredi
     [not found]                               ` <20050704084900.GG15370@elf.ucw.cz>
2005-07-04  9:02                                 ` Miklos Szeredi
2005-07-04 10:46                                   ` Pekka Enberg
2005-07-01 12:37                   ` bert hubert
2005-07-01  7:46                 ` Frederik Deweerdt
2005-07-01  9:47                   ` Miklos Szeredi
2005-07-01  9:36                 ` Frank van Maarseveen
2005-07-01 10:45                   ` Miklos Szeredi
2005-07-01 11:34                     ` Frank van Maarseveen
2005-06-30 10:16       ` Miklos Szeredi
2005-06-30 16:30         ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2005-09-02 22:02 Miklos Szeredi
2005-09-02 22:34 ` Andrew Morton
2005-09-03  0:34   ` Kasper Sandberg
2005-09-03  5:31   ` Miklos Szeredi
2005-09-03  6:40     ` Andrew Morton
2005-09-03  7:23       ` Miklos Szeredi
2005-09-03 13:29     ` Eric Van Hensbergen
2005-09-03 14:20       ` Miklos Szeredi
2005-09-03 15:01         ` Eric Van Hensbergen
2005-09-03 15:38           ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050701120028.GB5218@janus \
    --to=frankvm@frankvm.com \
    --cc=aia21@cam.ac.uk \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.