linux-kernel - Re: [PATCHSET] FUSE: extend FUSE to support more operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <491C0FA0.5070500@kernel.org>
Date:	Thu, 13 Nov 2008 20:29:36 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Miklos Szeredi <miklos@...redi.hu>
CC:	fuse-devel@...ts.sourceforge.net, greg@...ah.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHSET] FUSE: extend FUSE to support more operations

Hello,

Miklos Szeredi wrote:
> Not with '-oallow_other'.  Consider the case that the caller invoked a
> non well formed ioctl, but since there's no way to know this we
> allowed the fuse server to tinker with the caller's address space
> _as if_ the ioctl was well formed.

Right, allow_other.

> So we should always make sure that the server has enough privilege to
> read/write the caller's memory, i.e. it can ptrace the caller.
> 
> At this point we could allow any ioctls, not just well formed ones.
> But I don't want that for a different reason: if the possibility is
> there people will find new "innovative" uses for it and just get
> themselves into a big mess.

I don't really mind people doing strange things in userland as long as
it's safe but you're the maintainer.  It's a bit strange to export the
feature only for CUSE, so I'm a little bit hesitant.  I wanna make it
useful for both.  So, at the kernel level, only well formed for FUSE and
everything goes for CUSE.  Does that sound good enough?

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