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]

Date:	Tue, 14 Oct 2008 11:37:14 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	tj@...nel.org
CC:	fuse-devel@...ts.sourceforge.net, miklos@...redi.hu,
	greg@...ah.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCHSET] FUSE: extend FUSE to support more operations

Hi Tejun,

On Tue, 14 Oct 2008, Tejun Heo wrote:
> Hello, Miklos.
> 
> I'm about ready to send the next round of this patchset w/ mmap support,
> which I'm sure gonna stir up some discussion. :-) Several things I wanna
> hear your comments about.

Great.  Just yesterday evening I was looking through your patches to
see which ones I can submit for 2.6.28, and I've already applied

  0001-FUSE-add-include-protectors.patch
  0003-FUSE-implement-nonseekable-open.patch

Comments about the others:

  0002-FUSE-pass-nonblock-flag-to-client.patch

this is not needed, f_flags are already passed to userspace for read
and write.

  0004-FUSE-implement-direct-lseek-support.patch

this is trickier to get the interface right I think.  If we want to
allow filesystems to implement a custom lseek, then we also want them
to keep track of the file position, which means we must differentiate
between a write(2) and a pwrite(2) and similarly for reads.  AFAICS
this isn't needed for CUSE so we can leave this to later.

  0005-FUSE-implement-ioctl-support.patch

See below.

  0006-FUSE-implement-unsolicited-notification.patch
  0007-FUSE-implement-poll-support.patch

This would be nice, but...  I don't really like the fact that it uses
the file handle.  Could we have a separate "poll handle" that is
returned in the POLL reply?

> 1. I'll try to incorporate all other comments here but regarding ioctl I
> don't think we've reached any better solution, so I'm sticking with the
> original one.

I still got qualms about this ioctl thing.  One is the security
aspect, but that could be dealt with.  The other is that I really
really don't want people to start implementing new custom ioctls for
their filesystems, as I think that way lies madness.  We could limit
ioctls to CUSE and that would be fine with me.  Or for non-CUSE users
we could enforce the "standard" format where the type and length is
encoded in the command number.

I don't have any problems with the iterative way you implemented
ioctls.  We just need some additional restrictions to the current
implementation, I think.

> 2. You told me that the version branching in the userland library wasn't
> necessary.  Can you explain to me when FUSE version bumping is necessary?

The version number has to be bumped anyway.  But if you are only
adding new functions to the end of fuse_operations and
fuse_lowlevel_ops, then the interface can handle that, without needing
new compatibility functions.

> 3. Any other things on you mind?

One other thing I was thinking about is that do we really need
emulated char devices to be char devices?  What I mean is, what would
happen if instead of a char device /dev/dsp would be a regular file
mounted on /dev/dsp (which implements all the necessary interfaces:
ioctls, poll, etc)?

Thanks,
Miklos
--
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/