From: John R. M. <nig...@co...> - 2006-09-26 13:45:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello. I am looking at FUSE file systems and trying to determine if there is a portable way to do transparent access to files. Most FUSE drivers seem to operate in the following way: compress_encrypt_rbac_etc_fs base_dir mount_point Where some file system (for compression, encryption, rbac, etc; just not network file systems or anything else not using existing files) takes a base directory and ties it to a new directory. I would rather see it possible to set something like EncFS or LayerFS up such that you can just point it at a directory and have it fall straight through; that is, the FUSE driver accesses the underlying files directly. The only reference I can find to this involves hackish methods of opening a directory and fchdir()ing to it after mount, which aren't guaranteed to work. One question I have is whether it makes sense for a FUSE driver to access its own mount point; wouldn't it in theory have to go through itself, and thus probably hit an infinite loop? Assuming most drivers do not have to directly access the file system they export, it would make sense for drivers to be able to request FUSE perform the look-up through the kernel VFS to the file system directly under them (be it real or another FUSE driver...). For instance, the following could occur: static int tr_open(const char *path, struct fuse_file_info *fi) { int fd; /*open /path/to/mount/tr.dbfile*/ fd = fuse_direct_open("/tr.dbfile",O_RDWR); ... } This would be extremely useful for systems like LZOLayerFS, EncFS, or transparent RBAC systems (SELinux in Userspace?) where you usually mount dir -> dir. In the case of RBAC systems it would eliminate having a /path/to/realroot -> / which is broken (both from the real root being under the mountpoint, and from that fixing this you can evade it by going to /path/to/realroot). - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond We will enslave their women, eat their children and rape their cattle! -- Bosc, Evil alien overlord from the fifth dimension -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRRku1ws1xW0HCTEFAQJtgg/9FWKDdkmIA8KWUyW04YafXc3ISJkRvyo8 bBklErOvc5g+0C+k9CzreEbTlnggbyXUOxRhaH0yhFSdGVzECsoDKriC6Nu62nQK /pl0f1HM+OhR8rbxFDhABK103+17oiahQPBAcu/UnVzmgmd3nBZm+6UnVbEOElUT eg00ugrxCMjKI6T2mrjbsfixUycpWCeZa02hDEE+AlmDQggyhCUTprtyCNifqKgo NQUodq/ZWldsNm48RzsLDp0gY/iI3FvbDgY/+cWoepLP1DJnMIt9esLmmbYruswj UFndEQWZhApJhCs5omxumkZ3sJqAIdndhr5rfFX3YCXeKW2holHrXZzO2yVquGaB fHE8os2+SNsbXnINQcT1D3b38ubs8xw1AwL4B97nUlZaA61vEGyz2YlWJt8UbGBC FljIeysA4HB91ECjMuZkHTIHN+HqLhaKGbYp39TF3wg677tzxGg9vSVEN1OAGEsH chDwOJ7tDK98oJrPbeXF/qtBKBqI64LqBxiwKCfiEeiHYYmSSrzSnAFhz8ZNguvr AQRp4+yjsDRsbhP3aTxP4+ND+y+FiuT8Gbv2bW5mxltpFsPvH+MwYzaY0jJqQmHW t8/84qIzcWlX0CIU7Ei0GB1Vnk4Z8EjwO3JbC/ZZ59hr5eCsCfAQkhcaJ9hmAq5y 3XIuKCT6uFc= =Amry -----END PGP SIGNATURE----- |
From: Miklos S. <mi...@sz...> - 2006-09-26 15:52:19
|
> I am looking at FUSE file systems and trying to determine if there is a > portable way to do transparent access to files. Most FUSE drivers seem > to operate in the following way: > > compress_encrypt_rbac_etc_fs base_dir mount_point > > Where some file system (for compression, encryption, rbac, etc; just not > network file systems or anything else not using existing files) takes a > base directory and ties it to a new directory. > > I would rather see it possible to set something like EncFS or LayerFS up > such that you can just point it at a directory and have it fall straight > through; that is, the FUSE driver accesses the underlying files > directly. The only reference I can find to this involves hackish > methods of opening a directory and fchdir()ing to it after mount, which > aren't guaranteed to work. > > One question I have is whether it makes sense for a FUSE driver to > access its own mount point; wouldn't it in theory have to go through > itself, and thus probably hit an infinite loop? > > Assuming most drivers do not have to directly access the file system > they export, it would make sense for drivers to be able to request FUSE > perform the look-up through the kernel VFS to the file system directly > under them (be it real or another FUSE driver...). > > For instance, the following could occur: > > static int tr_open(const char *path, struct fuse_file_info *fi) > { > int fd; > /*open /path/to/mount/tr.dbfile*/ > fd = fuse_direct_open("/tr.dbfile",O_RDWR); > ... > } or more generally there would be next_open(), next_read(), etc. functions, and such 'filter' filesystems could be stacked on top of each other. See this project for a working prototype: http://sourceforge.net/projects/fsfipi Miklos |
From: John R. M. <nig...@co...> - 2006-09-26 19:33:20
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Miklos Szeredi wrote: ... > > or more generally there would be next_open(), next_read(), > etc. functions, and such 'filter' filesystems could be stacked on top > of each other. > > See this project for a working prototype: > > http://sourceforge.net/projects/fsfipi > It looks like this implements a FUSE driver and then implements file systems on top of it. Are the next_open(), next_read(), etc operations going to be actually added to the FUSE API, or is this going to be a file system daemon that loads other file system daemons? > Miklos > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond We will enslave their women, eat their children and rape their cattle! -- Bosc, Evil alien overlord from the fifth dimension -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRRmAdgs1xW0HCTEFAQJvoQ/+LFhKMtQHSlvsw0HmnbWm2fSuus79N4R+ OhzBYPFXrafjNdPEEcA6+IaofSpGh5+6yZp68Ueda8vSC0oLJ1gaMAkrrGnJSbJK 2dsdc7M9HR4lJ/f+7A8k2G++vAIm0vXjnpxYmSffvvoK3Y/g3wJspluB5TcG5Bdu JMxOHBS0hRPGRG3IRw59X/ounQ3KYQTOnLo0l4UlVfKC/SzfWFScQOQ3iZpwefft MtkelunoebNtNrzIlLDd+hJKv1WWch96gcTBOl9XZUVMmxuKBxAKR+yaAuLjsKxX jAk3SGz7yjL6ZI2xPqDCoCzCLqk9iw4HFXZLvfAWXnwK1T5n11mo4MI6+DsVrt6O +3WeFWJOTZleCyQHyyC9OnpMqBDXxiZYUbaq4T1m0VKgJnZNG1QVRoX+POY+iBVM Pk8R3Rq/QbWRQ1z0hhnSvuP1+fhDJAaDJ6oo8RldKUkUGR4GMWMA+tBB2oV5zzPk 0KBvsOoYkHHGYZI24A4StcjpFGOz73l2UzNitp7IDXmTW1RjVWI/0pGpwmKH/mTY kVyqIQjq2oco/QdVGVPqsSLCzYlYsWBduh51K62ulHorwHkr/GKvRWTJqT3d9G0k bRTY9HHDYOPzGCSeh70K1EM1wODcdiTiwPac4vbFF6mmDnXr11xDCFULaXyttOWp QOQufS2RiLU= =f1ch -----END PGP SIGNATURE----- |
From: Miklos S. <mi...@sz...> - 2006-09-30 17:23:24
|
> > or more generally there would be next_open(), next_read(), > > etc. functions, and such 'filter' filesystems could be stacked on top > > of each other. > > > > See this project for a working prototype: > > > > http://sourceforge.net/projects/fsfipi > > > > It looks like this implements a FUSE driver and then implements file > systems on top of it. Are the next_open(), next_read(), etc operations > going to be actually added to the FUSE API, or is this going to be a > file system daemon that loads other file system daemons? It will be part of the API. Hopefully in 2.7 release. I've been promising this for a long time, but somehow never got around to actually doing it. Miklos |
From: John R. M. <nig...@co...> - 2006-09-30 18:02:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Miklos Szeredi wrote: >>> or more generally there would be next_open(), next_read(), >>> etc. functions, and such 'filter' filesystems could be stacked on top >>> of each other. >>> >>> See this project for a working prototype: >>> >>> http://sourceforge.net/projects/fsfipi >>> >> It looks like this implements a FUSE driver and then implements file >> systems on top of it. Are the next_open(), next_read(), etc operations >> going to be actually added to the FUSE API, or is this going to be a >> file system daemon that loads other file system daemons? > > It will be part of the API. Hopefully in 2.7 release. I've been > promising this for a long time, but somehow never got around to > actually doing it. > That is awesome. I'm looking forward to it; perhaps I'll pick up on a defunct project of mine to implement an RBAC system (like grsecurity's or SELinux) in userspace :) (granted I can't control access to resources quite as fine-grained) > Miklos > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond We will enslave their women, eat their children and rape their cattle! -- Bosc, Evil alien overlord from the fifth dimension -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRR6xDQs1xW0HCTEFAQJ3ZQ//XdEs2h64Mx1prLOBoYLrw3umClmvFKmJ ETvy24EZzcWMYCMAcfijrXFUt+WvArkWGehlgOi/LwAJdZa49u3QF7h3lwxfYWS+ KuL29vW8vRELA562feaqcB3QMTJoXNDtLADp5h+6dD/Rasivyfp/abUti8GbOBfe d7AFlGDYfNvqjZBt7e/NdzTcLadvaFdQ1CGaDcVlbFNj6j3KjO2OyLcR6+Qgsu4p SOG2q3OYfjtRflll+yWi7abAryhsKC+lE4kRvoWVmhOJOv/Pz2lfI6uUlILTTqb3 D0HnmxlF2ty2BoQWFPbJ4h+Ld/70yawoy487D5fLH/vZJv7rVd4oPI/YxUMja95U 4DhknfmbxaBlpaRIt7Z9yXJGg4nvOnj/GlDcIGKrtg8/n2kRVi/EcQ7klmbL1rSL 337c3G3pme6XQ39/2uhnTeF1sEO1UfOI44UBV7hYdgjxxW4lNsddQXKzAACtYOHn RMkaJAPVxGpM/EJIeCfKmBB17p6RyGDUwl4x0QW28t3GoL61XXN/Vu0lzz46wHp9 MCd2HQlsx6TNvGGmAXRDaFkZLaCxTmGuQP6tP9WsYVv+r772Wnn3XulFp4Y4EVzu EWJiuYZIt+M/5YBVRWHzXVPSu+TvZyl65f5ybGWsWguzL/vJcT9oDeH4MgMF/uS5 eatYBlZWlmU= =mfPU -----END PGP SIGNATURE----- |