[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
people).
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
happen.
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
plan.
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
control?
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:
