Issue Details (XML | Word | Printable)

Key: CORE-1038
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Nickolay Samofatov
Reporter: m_Th
Votes: 0
Watchers: 2

If you were logged in you would be able to see more operations.
Firebird Core

Remote shadows on NT-based systems

Created: 03/Dec/06 10:07 AM   Updated: 22/Aug/16 06:00 AM
Component/s: Engine
Affects Version/s: None
Fix Version/s: 2.5 RC1

Environment: Windows 2000 and above

Planning Status: Considered for inclusion
Target: 2.5.0
QA Status: Cannot be tested

 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   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
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:

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)