At 04:34 PM 26/04/2005 +0000, you wrote:

>Right. But in this case, I'd have to modify the alias.conf everytime
>someone wants to create a database.

Presumably, someone with enough implicit privilege to create a database has
enough implicit privilege to access aliases.conf. No? It should be a
no-brainer to write a little utility to add a record to aliases.conf before
the CREATE DATABASE statement is submitted.

>
> > The problem probably lies with the fact the OS uses its System/User Path
> > variables to determine where the root is, in your case its looking at
> > $(system32)\Data\...
>
>Actually, the C:\Windows\System32 directory is where services.exe
>lives. Services.exe is responsible for executing each service in the
>services registry. So, the OS path for services.exe is the root path
>as far as the OS is concerned. When the firebird server gets a request
>to create a file, I would think that it should either:
>
>a- Base that off the root directory, not the OS default
>or
>b- Allow specification of the default file path (which is what I
>though setting RootDirectory was supposed to do).
>
> > This error will occur if the path C:\WINDOWS\SYSTEM32\DATA\ does not
>exist
> > or the process running Firebird does not have RW access to said path.
>
>Actually, the error part is expected because I'm restricting where
>databases are allowed to go. My expectation was that, since I'm
>restricting databases to certain locations, that firebird wouldn't
>default to a location that wasn't one of those locations.

Currently, the firebird.conf parameter DatabaseAccess with RESTRICT
restricts creation of/access to databases to the directory trees named (it
can be a semicolon-separated list). There's a feature request on the
drawing board for Fb 2 to make the first root in the list to be the default
database directory.

> >
> > > The only way for a remote user to create a database in my
> > > E:\Firebird_1_5\data directory is for them to expressly
> > > specify that path.
> >
> > Unless the alias is pre-specified in aliases.conf.
>
>And that involves intervention by the administrator (to modify the
>aliases.conf) and (I assume) a server restart to pick up the new alias.

That depends on the platform, of course. No, the server does not have to
restart to pick up a new alias. (You're thinking of firebird.conf).

>
> > No, its used to specify the install directory of FB, not the default
>data
> > directory. It would (imo) be a nice enhancement if you could specify a
> > default data directory.
>
>I agree, although it seems as if I'm doing that in my firebird.conf
>file when I'm specifying:
>
>DatabaseAccess = Restrict E:\firebird_1_5;E:\firebird_1_5\data
>
>Thanks for your input. Seems to be inconsistant behavior to me. Does
>anyone else agree?

No, it's not inconsistent behaviour. It's a trade-off between convenience
for the developer and filesystem security. Firebird doesn't assume
anything about filesystem permissions and does not have the capability to
modify them. With a platform-portable system, that would be a complete
rat's nest and not a place Firebird will ever go.

However, there's [almost] unanimous agreement that it would be useful to
extend DatabaseAccess = RESTRICT so that the engine can assume a
default. *That* is a perfectly reasonable extension of RESTRICT
protection. It's still going to be up to the SysAdmin to implement the
appropriate filesystem privileges for the Firebird process owner.

There's more coming in Fb 3, via Vulcan's new plug-in access features. I
don't have a fine analysis available, nor a crystal ball to predict how
exactly the Fb 3 implementation will be done. The plan is to allow for
multiple layers of access, as finely-grained as it needs to be, starting
from the connecting IP address and filtering down to configured "legal"
directory locations.

./heLen