[gecko-devel] Re: Some thoughts on sqlfs, etc..

  • From: "Matthew J. Sahagian" <gent@xxxxxxxxxx>
  • To: gecko-devel@xxxxxxxxxxxxx
  • Date: Fri, 16 Jan 2004 12:34:56 -0500

After having rewrote replies to various parts of this e-mail and after much 
thought, I've come to see that implementing such a device seems to be a much 
better way for interfacing sqlfs and sqlfsd with each other.  However, it does 
bring up many questions which I will post here for the sake of ideas, whehter 
from Aaron or from anyone else on the mailing list (if there is such other 

First off, my reasons why I've decided that this is the better option.

1) sqlfsd will already have to interface through a socket.  Since sqlfsd's job 
is to retrieve the information from the mySQL database it will be utilizing a 
socket to request and transfer that inforamtion.  This seems safe enough 
because sqlfsd is running in user-space.  This of course was the original point 
of sqlfs+sqlfsd in combination, as we would not want something running in 
kernel space to be working directly with the MySQL database.

2) The need for encryption is a must. While this was already established with 
the transmission of data between MySQLD and sqlfsd, utilizing another socket 
for sqlfsd's communication with sqlfs means that yet another component has to 
be SQL aware.  The only issue here is to ensure that once sqlfsd decrypts the 
said information that information doesn't remain resident in memory.  We'll 
either have to zero it out or place some other method to ensure this doesn't 

3) It's just a cleaner way of doing it, using sockets for everything is not the 
answer, particularly when there are other means of doing what we want.

Next comes a few questions or comments I have that arise out of the new design 

1)  ioctl() is messy.  Not necessarily implemented messy, it's just very broad. 
 As Robert Love points out in Linux Kernel Development, ioctl is a good example 
of what NOT to do with system calls, as it's behavior varies depending on it's 
flag argument.  In short, I'd like to stay way from it if we can, but I do 
realize it may come in handy.

2) The implementation of /dev/sqlfsXX devices is seemingly mixed in what it's 
goal is.  It's obvious goal is to provide a communication mechanism between 
sqlfs and sqlfsd, however, will it also provide a somewhat raw interface to the 
database via sqlfsd?  If this is the case it's identity as a character device 
is flawed.  In my last example (which should have been: cat /dev/zero > 
/dev/sqlfsXX not with two >'s), /dev/sqlfsXX would have to be more akin to a 
block device.  Otherwise sqlfsd would simply be seeing it as a stream of 0's 
and trying to interpret it's meaning.  While I'm fine implementing it as a 
character device, traditionalists will want to know why they cannot "zero out" 
their database using such means.  Afterall, the database relates to it's 
storage on a block device, and the ability to handle it as a block device 
should be there, at least some will argue.  

3) Are we ensured security through /dev/sqlfsXX permission alone?  It would 
appear that way as any read(), write()'s done still have to go through the 
kernel.  In that sense however, would an abstract socket not have the same 

Well, that's about all I can think of for now.  At this point I most definitely 
agree that we should implement the communications medium as a character device, 
it's just how to settle some of those issues that I mentioned.  Remember that 
one goal in implementing this is that all normal file operations can be done on 
the sort of pseud-files presented to the user via sqlfs.  ls -l /etc/passwd  
WILL return all necessary information and it will be correct, likewise an cd 
/etc ; ls will return a list of all available files.

I suppose this calls for a rewrite of the technical draft though, however, I'll 
wait until we're sure that this is exactly how it should be done.

On Fri, 16 Jan 2004 12:04:18 -0800 (PST)
Aaron Conole <apconole@xxxxxxxxx> wrote:

> > The original plan for the design was going to use a
> > pipe or socket in order to transfer the information.
> The problem here is network is inherently insecure. FS
> drivers are device drivers, and although we __could__
> do network reads/writes even to a local loopback
> device, it exposes yet another network attack vector
> in the kernel, which is evil....

Other related posts: