[#CORE-1038] Remote shadows on NT-based systems

Firebird Core

Remote shadows on NT-based systems

Created: 03/Dec/06 10:07 AM Updated: 12/Nov/09 05:18 PM

Component/s:

Engine

Affects Version/s:

None

Fix Version/s:

2.5 RC1

Time Tracking:

Not Specified

Environment:

Windows 2000 and above

Target:	2.5.0
Implementation:	Easy
Planning Status:	Considered for inclusion

Description

« Hide

Relax a bit the parsing engine in order to allow creating remote shadows on Windows LAN ie Create shadow 1 '\\<Server>\<Share>';

All

Comments

Work Log

Change History

Version Control

Subversion Commits

Sort Order:

[ Permalink | « Hide ]

Mark Jones added a comment - 01/Sep/07 10:01 PM

The company I am doing some work for at the moment is also interested in doing this. I have done some research and a small change that allows this to work but I came across some additional security issues.

Firstly I see that there is talk about changing the RemoteFileOpenAbility flag in some other threads:
http://sourceforge.net/mailarchive/forum.php?thread_name=46D7F36B.5080005%40xvision.it&forum_name=firebird-devel
http://sourceforge.net/mailarchive/message.php?msg_name=45B883EA.4060301%40insi.yaroslavl.ru

But this flag only current works for NFS shares, and furthermore it has no effect if NO_NFS is defined in the code - which is defined for WIN_NT, FREEBSD, NETBSD, VMS

I am unsure if this RemoteFileOpenAbility change is on anybody's todo list at this point. (if not I would probably be capable of doing it)
If this change was to be done then it should inherently allow shadow files to be able to be placed on remote drives (and so would other types of files like DB files)
This change might have to be for embedded and super server only? Unsure if it would be safe for classic?

But there are some security problems under windows...
Since the fbserver processing is running as a service under the LocalSystem (SYSTEM) account it cannot make a connection through to the network share as it fails with username/password error. Changing the firebird service to run as a different user and giving that user r/w permissions for the remote share - and it all works nicely.
But I am thinking that a another possible solution would be to allow the username/password to be embedded into the share name e.g. user:password@\\server\share\shadowfile and the server can make the connection to the share using the provided credentials.
It has been many years since I have used nfs so unsure if it will suffer a similar problem (but I kind of doubt it)

[ Show » ]

Mark Jones added a comment - 01/Sep/07 10:01 PM The company I am doing some work for at the moment is also interested in doing this. I have done some research and a small change that allows this to work but I came across some additional security issues. Firstly I see that there is talk about changing the RemoteFileOpenAbility flag in some other threads: http://sourceforge.net/mailarchive/forum.php?thread_name=46D7F36B.5080005%40xvision.it&forum_name=firebird-devel http://sourceforge.net/mailarchive/message.php?msg_name=45B883EA.4060301%40insi.yaroslavl.ru But this flag only current works for NFS shares, and furthermore it has no effect if NO_NFS is defined in the code - which is defined for WIN_NT, FREEBSD, NETBSD, VMS I am unsure if this RemoteFileOpenAbility change is on anybody's todo list at this point. (if not I would probably be capable of doing it) If this change was to be done then it should inherently allow shadow files to be able to be placed on remote drives (and so would other types of files like DB files) This change might have to be for embedded and super server only? Unsure if it would be safe for classic? But there are some security problems under windows... Since the fbserver processing is running as a service under the LocalSystem (SYSTEM) account it cannot make a connection through to the network share as it fails with username/password error. Changing the firebird service to run as a different user and giving that user r/w permissions for the remote share - and it all works nicely. But I am thinking that a another possible solution would be to allow the username/password to be embedded into the share name e.g. user:password@\\server\share\shadowfile and the server can make the connection to the share using the provided credentials. It has been many years since I have used nfs so unsure if it will suffer a similar problem (but I kind of doubt it)