From: Manuel E. S. <ran...@ra...> - 2002-12-04 11:13:29
|
Hello, First of all, thanks for writing such an interesting tool as FUSE. I am planning to implement a debuging/reverse-engineering tool as a FUSE file system, my intention is to write a forwarind filesystem so I can then get in the middle and see what comes and goes between userspace and the real filesystem, but I need to play with ioctl's and FUSE doesn't seam to support them. I'll try to add ioctl support to FUSE, but I am quite new to it, so I would apreciate any suggestions. Would you accept an ioctl support patch? Since ioctl forwarding is probably harder to implement securely in the kernel, it could be reserved to root or restricted somehow. Thanks for reading ranty -- --- Manuel Estrada Sainz <ra...@de...> <ra...@bi...> <ra...@us...> ------------------------ <man...@hi...> ------------------- Let us have the serenity to accept the things we cannot change, courage to change the things we can, and wisdom to know the difference. |
From: <Mik...@et...> - 2002-12-04 11:44:35
|
Hi! > I am planning to implement a debuging/reverse-engineering tool as a > FUSE file system, my intention is to write a forwarind filesystem so I > can then get in the middle and see what comes and goes between > userspace and the real filesystem, but I need to play with ioctl's and > FUSE doesn't seam to support them. > > I'll try to add ioctl support to FUSE, but I am quite new to it, so I > would apreciate any suggestions. It's not clear to me how would you use ioctls since they are meaningless on normal files, and on device files the filesystem implementation usually does not care about the ioctl operations. And even if you manage to hack fuse to intercept device ioctls, you wouldn't be able to do anything with them, because they contain arbitrarily structured data (not length/value as in the case of read or write). > Would you accept an ioctl support patch? > > Since ioctl forwarding is probably harder to implement securely in the > kernel, it could be reserved to root or restricted somehow. I think it is impossible, but you can try to convince me otherwise :) Miklos |
From: Manuel E. S. <ran...@ra...> - 2002-12-04 12:22:18
|
On Wed, Dec 04, 2002 at 12:44:18PM +0100, Miklos Szeredi wrote: > Hi! > > > I am planning to implement a debuging/reverse-engineering tool as a > > FUSE file system, my intention is to write a forwarind filesystem so I > > can then get in the middle and see what comes and goes between > > userspace and the real filesystem, but I need to play with ioctl's and > > FUSE doesn't seam to support them. > > > > I'll try to add ioctl support to FUSE, but I am quite new to it, so I > > would apreciate any suggestions. > > It's not clear to me how would you use ioctls since they are > meaningless on normal files, and on device files the filesystem > implementation usually does not care about the ioctl operations. And > even if you manage to hack fuse to intercept device ioctls, you > wouldn't be able to do anything with them, because they contain > arbitrarily structured data (not length/value as in the case of read > or write). Thanks for the comments. > > Would you accept an ioctl support patch? > > > > Since ioctl forwarding is probably harder to implement securely in the > > kernel, it could be reserved to root or restricted somehow. > > I think it is impossible, but you can try to convince me otherwise :) I didn't really look much into it, I guess that you are probably right. I'll try to do it for my own purposes and if I manage to do it somewhat cleanly I'll try to convince you. Thanks for the quick reply ranty -- --- Manuel Estrada Sainz <ra...@de...> <ra...@bi...> <ra...@us...> ------------------------ <man...@hi...> ------------------- Let us have the serenity to accept the things we cannot change, courage to change the things we can, and wisdom to know the difference. |
From: Manuel E. S. <ran...@ra...> - 2003-01-11 17:39:07
|
Hello again, I finally quit and went for a simpler one way dumping module for my reverse engineering purposes, I could send the code to the list or personaly in case you are curious. But I hate to waste time and code. I'll attach my changes and comment on the issue, just in case it could be usefull. On Wed, Dec 04, 2002 at 12:44:18PM +0100, Miklos Szeredi wrote: > > I am planning to implement a debuging/reverse-engineering tool as a > > FUSE file system, my intention is to write a forwarind filesystem so I > > can then get in the middle and see what comes and goes between > > userspace and the real filesystem, but I need to play with ioctl's and > > FUSE doesn't seam to support them. > > > > I'll try to add ioctl support to FUSE, but I am quite new to it, so I > > would apreciate any suggestions. > > It's not clear to me how would you use ioctls since they are > meaningless on normal files, It does have meaning for normal files, like FIBMAP, FIGETBSZ or FIONREAD. Filesystems could also implement some extra operations via ioctl, like setting some non-standard attribute or something. > and on device files the filesystem implementation usually does not > care about the ioctl operations. You are right on this one, but in may case, my victim was a file within usbfs, which is implemented as a regurar file, not a device file. > And even if you manage to hack fuse to intercept device ioctls, you > wouldn't be able to do anything with them, because they contain > arbitrarily structured data (not length/value as in the case of read > or write). For well behaved ioctl's, you can use _IOC_SIZE to find out the size of the argument. And if needed some heuristic could be added in kernel space to know how to pack the argument of some 'not so well behaved' ioctl's. I did that for USBDEVFS_CONTROL ioctl. > > Would you accept an ioctl support patch? > > > > Since ioctl forwarding is probably harder to implement securely in the > > kernel, it could be reserved to root or restricted somehow. > > I think it is impossible, but you can try to convince me otherwise :) As a general purpose debugging/reverse-engineering tool it is probably unresonable (a lot of heuristic would be needed) but it would be quite easy to allow fuse filesystems to implement simple well behaved ioctl's. About the patch: - Just fusexmp will depend on glib. Sorry, but it was much simpler to do that way. - Adds 'struct fuse_file' to be used instead of 'const char *path' here and there. - It contains priv_fd, which allows fuse filesystems to keep files opened and close them when the associated fuse file gets closed. - Makes it easier to add more information on files without changing function prototypes. - For a sample, look at fusexmp. It uses priv_fd. - Adds some kind of ioctl support. - REL2POINT/POINT2REL allows absotute pointers to be changed into relative indexes and viceversa to allow address space changing of complex ioctl arguments. - Such 'complex' ioctl's are probably not worth the effort thou. Hope you like it. ranty -- --- Manuel Estrada Sainz <ra...@de...> <ra...@bi...> <ra...@us...> ------------------------ <man...@hi...> ------------------- Let us have the serenity to accept the things we cannot change, courage to change the things we can, and wisdom to know the difference. |