Menu
▾
▴
firebird-devel
|
From: Alex P. <pe...@in...> - 2004-09-23 11:46:28
|
Hi! Jim Starkey wrote: > If you have a solution you will save dozens of users from opening > database with different path names, getting different lock tables, and > trashing their databases. If you've got a fix, the lock manager needs > it. > Yes, I have a solution. But I need some advice. The real problem is between filename expansion and y-valve. Remote susbsystem absolutely correctly maps local name (like x:\dir\db.fdb) to full remote name (\\ouserver\!favorite_share!\dir\db.fdb) and tries to invoke our own server WNet listener. But it may be configured not to listen to WNet! Or some other error happens (in my case I have 2 firebirds running on same box - production and development, dev uses port 3060 and doesn't accept WNet and local connections. They are separated also by DatabaseAccess in firebird.conf not to have access to same databases). Therefore remote reports error and y-valve passes x:\dir\db.fdb to local susbsytem to process. ISC_expand_filename() doesn't check for remote drive and opens database like local. It's easy to learn ISC_expand_filename() to check for remote mounts. But it's used in many places of engine and not everywhere (external table is example) this will be good. Now my ISC_expand_filename() expands mount points only when called from y-valve (additional parameter added). Does such approach seem correct to you? Another variant - change y-valve. May be it's worth learn him to distinguish between "no, that's not my database" answer and "this is my database, but failure happened opening it - don't try anymore". But here your advice is much more needed. Alex. |
|
From: Jim S. <ja...@ne...> - 2004-09-23 14:11:40
|
Alex Peshkov wrote: > Hi! > Jim Starkey wrote: > >> If you have a solution you will save dozens of users from opening >> database with different path names, getting different lock tables, >> and trashing their databases. If you've got a fix, the lock manager >> needs it. >> > Yes, I have a solution. > But I need some advice. The real problem is between filename expansion > and y-valve. Remote susbsystem absolutely correctly maps local name > (like x:\dir\db.fdb) to full remote name > (\\ouserver\!favorite_share!\dir\db.fdb) and tries to invoke our own > server WNet listener. But it may be configured not to listen to WNet! > Or some other error happens (in my case I have 2 firebirds running on > same box - production and development, dev uses port 3060 and doesn't > accept WNet and local connections. They are separated also by > DatabaseAccess in firebird.conf not to have access to same databases). > Therefore remote reports error and y-valve passes x:\dir\db.fdb to > local susbsytem to process. ISC_expand_filename() doesn't check for > remote drive and opens database like local. > > It's easy to learn ISC_expand_filename() to check for remote mounts. > But it's used in many places of engine and not everywhere (external > table is example) this will be good. Now my ISC_expand_filename() > expands mount points only when called from y-valve (additional > parameter added). Does such approach seem correct to you? > > Another variant - change y-valve. May be it's worth learn him to > distinguish between "no, that's not my database" answer and "this is > my database, but failure happened opening it - don't try anymore". But > here your advice is much more needed. > The problem is when the same filesystem is accessable both through a local disk and remote mount. As far as I know, ISC_expand_file doesn't handle this. I know you're thinking in term of 2.0, but perhaps before suggesting changes you might take at look how the Vulcan Y-valve works, particularly with regard to it's relationship with the configuration file. But to answer you question, it isn't (and never was) the Y-valve's job to pick a provider. It doesn't (and shouldn't) have the knowledge to do this. The Y-valve's job to poll subsystem to see if they can handle the connection. Exactly how the providers accomplish this task is an internal issue to the provider and none of the Y-valve's business. And if it isn't the Y-valve's job to know who a database belongs to, it is even less the job of a provider to tell the Y-valve to stop polling other providers. The purpose of the architecture is draw clear lines of responsibilty between the components. If done well, everybody's job is simpler and the pieces play well together. And if not, you have a mess. -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
|
From: Edward F. <ed...@cd...> - 2004-09-22 15:59:35
|
It doesn't matter if you encrypt passwords with crypt,MD5, or SHA. The problem here isn't the fact that these things are weekly encrypted. The problem is the fact that users (not just the server) can view all the encrypted hashes. This makes brute forcing anybody's insecure password, achievable in a VERY finite amount of time. Please consider changing the method of authentication to something along the lines of SRP (http://srp.stanford.edu) or SASL (http://www.ietf.org/rfc/rfc2222.txt) for modular authentication. And then make the users database unreadable to clients. Alex Peshkov wrote: > Jim Starkey wrote: > >> >> >>> The reason is simple. It's easy to protect your network connection >>> from sniffers using any tool you like. But currently it's impossible >>> to protect from 'select user_name, password from users;', no 3-rd >>> party software will help you. Any user can read hashes of all others. >>> We can solve this problem only inside firebird, for example, making >>> hashes harder to brutforce. >> >> >> >> Ah, clearly you have never run a network of Linux servers. The life >> expectancy of an out-of-the-box Linux from a disto is about 72 hours. > > > In one honey-net report I've seen even much smaller digits, for four > experimental boxes it varied from 19 minutes to 25 hours. > >> However, even without hackers, any PC user can put his ethernet board >> into promiscuous mode and get all traffic. > > > This means - if you want secure network, use switches, not hubs. > >> And if you leave your LAN, every node on any IP routing can read your >> traffic. Do you really want to hand them your passwords? >> > Certainly not, that's why if I need remote connection to firebird, I > always use zebedee. > >> If you don't believe in the strength of encryption, however, nothing >> works. For security design purposes, secure hash is presumed secure. >> In practice and known theory, SHA is secure. Loss of password over >> the wire is 10**10 more important than worrying that someone will >> break a secure hash. >> > Agreed, but I can protect from loss of passwords in network without > moification of engine (as described above). > >>> >>>> >>>> The reason that a security architecture is essential is to determine >>>> the relative strengths of the links and shore up the weaker. Sure, >>>> the existing cypt is a farce and should be replaced with SHA, but >>>> the rest of your proposal adds nothing to security and gets in the >>>> way of doing it right. >>>> >>> Without the rest of my proposals new hashes don't work, I mean don't >>> work reliably. Assume sysdba attaching to server with gsec version >>> 1.5. He successfully changes sysdba's password (yes, he is wrong, but >>> he is even not warned about!), but this is not SHA hash, this is >>> existing crypt hash. The only known to me way to save such database >>> is to copy it to the server with working firebird and use new gsec. >>> Almost all the rest of my proposals is to exclude such situation. >>> What about replacing crypt with HSA - it is certainly possible, but >>> plugins desision seems better. >> >> >> >> Why not just encode all new passwords with SHA (no choice) and check >> first for SHA then crypt. > > > And at any moment have a number of passwords in crypt, not SHA, due to > bad client, and without any warnings... I wanted to make default install > without attempt to check for crypt hash. > >> Then no changes are necessary in any tools. All a DBA has to do to >> cut over is redefine all passwords. It compatible, no worse than what >> is there now, and he can do it at his leasure. >> >>> Why force people using one and only one kind of hash? Experts now say >>> that SHA is safe, but when current crypt was used it also seemed to >>> be OK. >> >> >> >> Crypt is what all Unix systems used at the time. Not much point in >> being more secure than the platform you run on. It was a bad choice, >> but better than rolling their own. In any case, they (the Borland >> guys) didn't think about it very much. >> > Sometimes it seems that they didn't think very much about many things. > Could they that time : > - calculate hashes on server, not client, > - add a feature to use plugins for creating hashes, > interbase might smoothly migrate from crypt to MDn and later to SHA-n. > >>>> >>>> Vulcan supports any number of security databases. Your scheme is >>>> useless in version 3. But since there is no reliable way to compare >>>> two Windows filenames (which is the source of endless database >>>> corruptions), your scheme doesn't even work in version 2. >>> >>> >>> >>> >>> Current isc_expand() seems to give reliable results for existing files. >> >> >> >> Alex, it doesn't. It can't detect that a local file with a remote >> mount are the same. That's how databases get trashed. It's also how >> to break your scheme. > > > Ouuh, that's a bug in ISC_expand_filename(). I haven't known about it. > Or may be it's a feature to access remote files on local sql server? I > see a clear way to fix it, but may be someone use it as a 'feature'? > > But on a box, where I tried to reproduce a problem it was a setting to > restrict database access in firebird.conf. Certainly, there was no path > on mounted disk in restrict-list. Therefore I was not able to get access > to security database using remote mount. But out-of-the-box installation > really makes it possible to do this trick. On the other hand, will > security database be trashed after such access? If yes, wrong hash in it > doesn't make any difference. > >> >>> May be there are special tricks to break this method, but being used >>> they will lead to corruption of security.fdb, as you mentioned >>> already, and I changed nothing here. I hope that this scheme will not >>> be needed in v.3 with new security architecture, but in version 2 it >>> is needed for one simple reason - help people avoid attaching to >>> security database using old versions of gsec, which used to build >>> hashes on the client. If sysdba wants to break security database (or >>> user wants to attach to it and write bad hash for hymself), certainly >>> he can do it, but this is not a trivial task, and he will not do it >>> accidentially, as it was really easy without this change. >> >> >> >> Again, it doesn't work in V2 and it's a non-starter in V3. >> >>> >>> May be - I trusted information reported by someone (Mark ? Sorry, >>> don't remember exactly) in fb* lists, that current hashes are not >>> enough strong for brutforce. I didn't try myself. >> >> >> >> This would be big news in the crypto community. If he can break SHA, >> he will be rich and famous. >> > No, crypt was mentioned there. It's some misunderstanding, sorry. I > meant crypt/DES. > > Alex. > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel |
|
From: Alex P. <pe...@in...> - 2004-09-23 10:55:55
|
Hi, Edward ! > It doesn't matter if you encrypt passwords with crypt,MD5, or SHA. > The problem here isn't the fact that these things are weekly > encrypted. The problem is the fact that users (not just the server) > can view all the encrypted hashes. This makes brute forcing anybody's > insecure password, achievable in a VERY finite amount of time. Please > consider changing the method of authentication to something along the > lines of SRP (http://srp.stanford.edu) or SASL > (http://www.ietf.org/rfc/rfc2222.txt) for modular authentication. And > then make the users database unreadable to clients. I shouldn't discuss the problem, can SHA be brutforced or not. Even if can't be now, who knows what will happen in a few years. What about making security database unreadable... I think that if my approach will be accepted for v.2.0, it will not be too hard to make it unreadable for _remote_ connections to any server, and for all connections to servers other than posix CS. I don't have in mind here cases like win9x and shared disk with fb installation:-), I mean 'it need not be readable for normal operation of correctly installed firebird'. But for local (embedded) connection on posix firebird is used as shared library, linked to user's process, which (user process) must be able to read security database to do authentication. Certainly, it's possible to think about some tricks here, but may be it's better to think about PAM authentication? Alex. BTW. If you write crypt plugin, using mentioned wonderful things like SRP or SASL, this will be nice. |
|
From: Edward F. <ed...@cd...> - 2004-09-23 17:57:33
|
Alex Peshkov wrote: > I shouldn't discuss the problem, can SHA be brutforced or not. Even if > can't be now, who knows what will happen in a few years. Right, thats why I was saying that the hash algorithm doesn't really mean anything. It can be bruteforced anyways. > What about making security database unreadable... I totally agree with that. > Certainly, it's possible to think about some tricks > here, but may be it's better to think about PAM authentication? PAM would be great for local authentication, but I don't think it works over the wire (unless you are using a kerberos PAM module or something, but correct me if I'm wrong). SASL is very modular and is meant for over-the-wire authentication, and with SASL there wouldn't be the need to implement individual authentication mechanisms, since its handled generically. Maybe doing both would be the way to go. > BTW. If you write crypt plugin, using mentioned wonderful things like > SRP or SASL, this will be nice. Maybe after I quit working 60 hours a week :-P. Ed |
|
From: Milan B. <mi...@km...> - 2004-09-23 10:16:46
|
Jim Starkey wrote: >> The reason is simple. It's easy to protect your network connection >> from sniffers using any tool you like. But currently it's impossible >> to protect from 'select user_name, password from users;', no 3-rd >> party software will help you. Any user can read hashes of all others. >> We can solve this problem only inside firebird, for example, making >> hashes harder to brutforce. > > Ah, clearly you have never run a network of Linux servers. The life > expectancy of an out-of-the-box Linux from a disto is about 72 hours. > However, even without hackers, any PC user can put his ethernet board > into promiscuous mode and get all traffic. And if you leave your LAN, > every node on any IP routing can read your traffic. Do you really want > to hand them your passwords? That is easily eliminated by using stunnel or zebedee on the same server where the Firebird is run. > If you don't believe in the strength of encryption, however, nothing > works. For security design purposes, secure hash is presumed secure. > In practice and known theory, SHA is secure. Loss of password over the > wire is 10**10 more important than worrying that someone will break a > secure hash. But the loss on wire is very easy to prevent. I know I'm not one of the core developers, but I wouldn't like Firebird to implement any SSL, SSH or similar protocol. I like it to stay quick-small-fast DBMS. Regards, -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |
|
From:
<car...@te...> - 2004-09-23 11:59:30
|
Hello: > But the loss on wire is very easy to prevent. I know I'm not one of > the core developers, but I wouldn't like Firebird to implement any > SSL, SSH or similar protocol. I like it to stay quick-small-fast DBMS. I think Firebird should implement SSL/TLS support in future versions but, obviously, it should be optional, you should be able to use a secure connection only if you really need it (as other RDBMS does like Postgres) -- Best regards Carlos Guzmán Álvarez Vigo-Spain |
|
From: Mark O'D. <mar...@fi...> - 2004-09-24 05:26:53
|
Hi Alex / Jim all. Alex Peshkov wrote: > Jim Starkey wrote: > >> >> The SHA hashes are considered by security >> experts to be secure. Both SHA-1 and MD5 are still considered secure. > > May be - I trusted information reported by someone (Mark ? Sorry, don't > remember exactly) in fb* lists, that current hashes are not enough > strong for brutforce. I didn't try myself. > The DES hash currently used in firebird (single DES8, not to be confused with tripple-DES) is pretty easily breakable. Using special hardware: 1998 $200,000 4.5days. http://www.schneier.com/crypto-gram-9808.html#descracker 2001 : $1,000 25.4hours http://ece.gmu.edu/crypto/ches02/talks_files/Bond.pdf A few years ago, someone else had a farm of 100MHz SUN workstations, (10 or so) and it took a week. Nowadays, nobody reports it anymore since it's pretty easy. >> >>> >>>> Trying to hide the hash is completely pointless. >>> No it's not - although that was the thinking in the 70's - and is why shadow password files were introduced to unix in the 80's. If you can get a list of encrypted passwords (say security.fdb) you can take them off to your own datacenter, then point your own cray cluster at them, to blaze away. That's less secure than having to politely try and logon to the system you are trying to break into, to test each combination, where hopefully after three login attempts you get either a delay or locked out. > >> >>> >>>> Hiding it in an ineffective manner is less than pointless. Communications will the client, over the net, should be done over ssl. It's usual to send a password to the server, over ssl, but so the server can read the raw password. Hiding the users password in security.fdb so it is not visible to users other than sysdba is effective. >> >> >> Yes, it is pointless. You can't block embedded access if the file >> can be read. All you can do is make it moderately inconvenient. >> Don't confuse "inconvenient" with "secure". > Classic/embeded has no security, other than you trust implictly the client. But that is also often acceptable, for instance when your "client" is actually a server (say an application server) itself. Cheers Mark |
|
From: Magnus H. <ma...@le...> - 2004-09-24 09:50:16
|
> The DES hash currently used in firebird (single DES8, not to > be confused > with tripple-DES) is pretty easily breakable. > > Using special hardware: > > 1998 $200,000 4.5days. > http://www.schneier.com/crypto-gram-9808.html#descracker > > 2001 : $1,000 25.4hours > http://ece.gmu.edu/crypto/ches02/talks_files/Bond.pdf > > A few years ago, someone else had a farm of 100MHz SUN > workstations, (10 > or so) and it took a week. Or one could use systems like RainbowCrack http://www.antsight.com/zsl/rainbowcrack/, which according to their site "crack 10 alpha-numeric windows password in 184 seconds". Using sites like http://sarcaprj.wayreth.eu.org/, you do not even have to do the initial calculation. Long story short, making the security database un-/less available really does make sense. Magnus |
|
From: eg <eg...@ju...> - 2004-09-22 15:47:44
|
Jim Starkey wrote: > Wrong on every count. The SHA hashes are considered by security experts > to be secure. SHA-1 produces a 160 bit hash, which is considered > unbreakable. ... I wouldnt be so sure about that. See the following article by Bruce Schneier. http://www.schneier.com/crypto-gram-0409.html#3 |
|
From: Milan B. <mi...@km...> - 2004-09-23 10:16:31
|
Alex Peshkov wrote: > It seems to me that I've described them in my letter - we can't prevent > stealing hashes of passwords (at least for CS on posix). Current hashes > may be relatively easy brutforced on a modern CPUs. Therefore let's try > to make them hard to brutforce. The best way is to let people use that > hashes they trust. Therefore - crypt plugins. Has anyone considered using LDAP for authentication (as an alternative)? Firebird would only need to hook up to LDAP and use it's mechanism for storing/checking passwords. It would enable easier administration (for users) and leave the password issue to the tool that is specialized for it. Just my $0.02. -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |
|
From: Alex P. <pe...@in...> - 2004-09-23 11:06:07
|
Milan Babuskov wrote: > Alex Peshkov wrote: > >> It seems to me that I've described them in my letter - we can't >> prevent stealing hashes of passwords (at least for CS on posix). >> Current hashes may be relatively easy brutforced on a modern CPUs. >> Therefore let's try to make them hard to brutforce. The best way is >> to let people use that hashes they trust. Therefore - crypt plugins. > > > Has anyone considered using LDAP for authentication (as an > alternative)? Firebird would only need to hook up to LDAP and use it's > mechanism for storing/checking passwords. It would enable easier > administration (for users) and leave the password issue to the tool > that is specialized for it. There many different auth methods. LDAP is not universal thing, some small networks don't use it. We should better think about having auth plugins - using them it will be able to use LDAP, PAM, NTLM, any other, supported by OS, or even our own, I mean keeping users' list in any database instead of special (personallu I don't like this idea, but if soneone needs such mode, he can do it). A. |
|
From: Jim S. <ja...@ne...> - 2004-09-23 11:19:12
|
Milan Babuskov wrote: > > Has anyone considered using LDAP for authentication (as an > alternative)? Firebird would only need to hook up to LDAP and use it's > mechanism for storing/checking passwords. It would enable easier > administration (for users) and leave the password issue to the tool > that is specialized for it. > A fine example of a prospective security plugin. |
|
From: marius p. <ma...@re...> - 2004-09-23 13:56:10
|
Jim Starkey wrote: > > > Milan Babuskov wrote: > >> >> Has anyone considered using LDAP for authentication (as an >> alternative)? Firebird would only need to hook up to LDAP and use it's >> mechanism for storing/checking passwords. It would enable easier >> administration (for users) and leave the password issue to the tool >> that is specialized for it. >> > A fine example of a prospective security plugin. maybe later we can keep passwords in mysql :) just kidding |
|
From: Paul B. <pb...@ib...> - 2004-09-27 15:27:53
|
Apologies, for my late reply to this. Jim, a complete overhaul of the security mechanism is required, but who will do it, and how long will it take to discuss? Your comments have merit, but are at a large tangent to the main issue here. Alex has attempted to fix some known issues re. security in the current implementation and improve for V2.0. I think we should be thanking him for the work he is doing, not criticising. Sorting out some of the obvious issues, required that someone make it happen... I for one would like to see Alex's work in 2.0, as I suspect would a lot of other users of Firebird. Paul |
|
From: Geoff W. <ge...@te...> - 2004-09-23 22:59:56
|
Hi All, Please excuse any ignorance displayed in this email :-) From=20what I understand it is possible to have Firebird authentication achieved through the operating system on Posix systems. I've never tried it myself. Has anyone (recently) looked at providing this capability in a consistent manner. That is; while we are talking about plug-ins... Why not remove the current Posix authentication and make it a plug-in. That way IF you want Posix authentication you have to plug it in, and default installations are not left with potential holes because of a feature that is not obvious. And then someone really bright could look at creating a Windows domain plugin. Something that authenticates a user via the Windows domain. For Windows networks this would be really convenient, because then the user need not have multiple usernames and passwords and Windows security policies could be used to centrally manage network access - including the Firebird server. If consistent operating system based authentication is feasible then surely it something we should strive to achieve. Besides the advantage of centralising user/password management it also means that various "plug-in" security options become automatically available on Linux because it already has this capability. I expect that this stuff has been investigated before, I was wondering if there are reasons why it may not be feasible. --=20 Geoff Worboys Telesis Computing |
|
From: Jim S. <ja...@ne...> - 2004-09-23 23:59:47
|
Geoff Worboys wrote: >Hi All, > >Please excuse any ignorance displayed in this email :-) > >>From what I understand it is possible to have Firebird >authentication achieved through the operating system on >Posix systems. I've never tried it myself. > > > Of course it feasible. It's even desirable. But we don't have a design for a security plugin. Collecting requirements and various security/authentications systems is one of the first steps. So keep the ideas coming. |
|
From: Geoff W. <ge...@te...> - 2004-09-24 00:35:43
|
> But we don't have a design for a security plugin. Collecting > requirements and various security/authentications systems is > one of the first steps. So keep the ideas coming. OK then :-) One of the annoying things about the existing arrangements is that users are identified by logon username rather than by some surrogate identifier. So if you use the USER variable to store the current user anywhere, such as defining roles and other permissions, then these definitions are tied to the literal. This prevents you from changing a users logon username (for example when people get married). I implemented a convoluted system of dual logons in one of my installations specifically so I could work around this restriction - but it turned out not to work all that well anyway :-( I do not know enough about the various different types of security systems that we may want to plug-in. But Windows for example does use a separate UUID to identify a user, allowing the logon name to change if needed. I dont expect we would be lucky enough for all possible security plug-in systems to use exactly the same types of user identifier. My lack of experience with other systems means that I really have no idea exactly how FB databases should implement support for storing user identifiers, but I begin to suspect that some sort of translation table may be required. Something that cross-references the plug-in defined user identifier to a consistent FB format identifier. There would then need to be an API that took a give FB user-id, translated it to a plugin user-id and then did an appropriate plugin call to discover the actual user logon name. This could make it interesting getting the list of users. Anyone else have any thoughts or experience on this? -- Geoff Worboys Telesis Computing |
|
From: Dmitry Y. <di...@us...> - 2004-09-24 10:17:14
|
"Geoff Worboys" <ge...@te...> wrote: > My lack of experience with other systems means that I really > have no idea exactly how FB databases should implement support > for storing user identifiers, but I begin to suspect that some > sort of translation table may be required. Something that > cross-references the plug-in defined user identifier to a > consistent FB format identifier. There would then need to be > an API that took a give FB user-id, translated it to a plugin > user-id and then did an appropriate plugin call to discover > the actual user logon name. This could make it interesting > getting the list of users. > > Anyone else have any thoughts or experience on this? My own vision is presented below. User should become a database object, like tables, roles, etc. This will allow reliable grants, defaut user roles and some other improvements. As a database object, it's being described by a standard SQL identifier (currently CHAR(31) UNICODE_FSS) which may be any valid string or number. Authentication is a completely different beast which is external to a database (although may interact with a database via Jim's engine callbacks, including storage of password information inside a database). Authentication is implemented via PAM, with some standard (legacy security.fdb, OS level, EUA, etc) plugins provided in the kit. Each auth mechanism (plugin) has a unique identifier/name (?) and a number of auth parameters (id, login, password, biometrical data or whatever else) identifying a given auth account. Each user is mapped to an external auth account. I'd propose something like 'CREATE USER <name> IDENTIFIED BY <auth_account_id>', but this is just me. For example, the current authentication may be described as IDENTIFIED BY 'login=<user>, password=<pwd>'. The used auth method may be stored in RDB$DATABASE, or provided in DPB, or specified in the IDENTIFIED BY stuff and hence stored in the users table... but I feel this is a completely different question to discuss. The pros of the aforementioned idea: 1) database user names and authentication ids are separated 2) users are stored inside the database, allowing some extra benefits 3) CREATE/ALTER/DROP USER are usual DDL commands always executed against the attached database 4) it's easy to switch from auth method to another without changing database users (or even allow different auth methods for different database users, although I'm nor sure this is good idea) P.S. This is not a proposal, but a call for some brainstorming. Dmitry |
|
From: Thomas S. <ts...@ib...> - 2004-09-24 11:08:35
|
Hi Dmitry, > > My lack of experience with other systems means that I really > > have no idea exactly how FB databases should implement support > > for storing user identifiers, but I begin to suspect that some > > sort of translation table may be required. Something that > > cross-references the plug-in defined user identifier to a > > consistent FB format identifier. There would then need to be > > an API that took a give FB user-id, translated it to a plugin > > user-id and then did an appropriate plugin call to discover > > the actual user logon name. This could make it interesting > > getting the list of users. > > > > Anyone else have any thoughts or experience on this? > > My own vision is presented below. > > User should become a database object, like tables, roles, etc. This will > allow reliable grants, defaut user roles and some other improvements. As a > database object, it's being described by a standard SQL identifier > (currently CHAR(31) UNICODE_FSS) which may be any valid string or number. > > Authentication is a completely different beast which is external to a > database (although may interact with a database via Jim's engine callbacks, > including storage of password information inside a database). Authentication > is implemented via PAM, with some standard (legacy security.fdb, OS level, > EUA, etc) plugins provided in the kit. Each auth mechanism (plugin) has a > unique identifier/name (?) and a number of auth parameters (id, login, > password, biometrical data or whatever else) identifying a given auth > account. > > Each user is mapped to an external auth account. I'd propose something like > 'CREATE USER <name> IDENTIFIED BY <auth_account_id>', but this is just me. > For example, the current authentication may be described as IDENTIFIED BY > 'login=<user>, password=<pwd>'. The used auth method may be stored in > RDB$DATABASE, or provided in DPB, or specified in the IDENTIFIED BY stuff > and hence stored in the users table... but I feel this is a completely > different question to discuss. > > The pros of the aforementioned idea: > > 1) database user names and authentication ids are separated > 2) users are stored inside the database, allowing some extra benefits > 3) CREATE/ALTER/DROP USER are usual DDL commands always executed against the > attached database > 4) it's easy to switch from auth method to another without changing database > users (or even allow different auth methods for different database users, > although I'm nor sure this is good idea) > > P.S. This is not a proposal, but a call for some brainstorming. Storing the user names in the database is an excellent idea if using the internal Firebird authentication, like it is now, but with the difference, that the user isn't server-wide, but database bound. If I understand the plugin idea correctly, there could be a LDAP, Kerberos, ... plugin, right? With these external authentication mechanism used, would it be still necessary to have the user created in the database? You know, you would have to maintain the user again in different places. Or, would it be possible to define that a database user is able to authenticate via LDAP or Kerberos or both? Just my 2 cents. Regards, Thomas PS: Great to see that there is work in that area in progress!!! |
|
From: Dmitry Y. <di...@us...> - 2004-09-24 12:01:38
|
"Thomas Steinmaurer" <ts...@ib...> wrote: > > With these external authentication mechanism used, would it be > still necessary to have the user created in the database? You > know, you would have to maintain the user again in different > places. Now you need to synchronize server and database anyway - deleting a server-wide user keeps its privileges in all databases, leaving a possibility for not expected database access when this user name is added again into security.rdb. IMHO, users along with their permissions and roles are objects of one group and should be stored together. Of course, having different users/logins brings some additional complexity. But it gives you some power as well. And also it allows to separate the external logic and database objects. Why on earth do you have to create SYSDBA and <owner> users in the NT domain just to be able to backup your database? Just map group "Domain Administrators" to the database-level SYSDBA and group "Backup Operators" to the database-level <owner>. Or use EUA for these users and NT domain authentication for everybody else. Also (again IMHO), it's easier to migrate such a database between hosts with different auth methods - just remap the database users to whatever you need. > Or, would it be possible to define that a database user is > able to authenticate via LDAP or Kerberos or both? I think it should be possible. Dmitry |
|
From: Vlad H. <ho...@sp...> - 2004-09-24 15:17:37
|
One addition :
if we plans to implement cross database joins (inside
one server), we must have ability to identify users in different
databases by its server logins.
I.e. when user with server login X logged in database D1
perform statement like
select ... from D1.table1 join D2.table2
where D1 and D2 are databases within the same server, we
must be able to autorize this user against database D2.
Refards,
Vlad
|
|
From: Jim S. <ja...@ne...> - 2004-09-24 15:40:26
|
Vlad Horsun wrote: > One addition : > > if we plans to implement cross database joins (inside >one server), we must have ability to identify users in different >databases by its server logins. > > I.e. when user with server login X logged in database D1 >perform statement like > > select ... from D1.table1 join D2.table2 > >where D1 and D2 are databases within the same server, we >must be able to autorize this user against database D2. > > > > This question has been around longer than Interbase. The great unwritten component is traditionally called the mega-database manager. The MDM is a provider (using Vulcan terminology) in which virtual databases are defined from a number of physical databases. The MDM manages virtual metadata, decomposes queries to underlaying databases, optimizes semi-joins, and generally acts as traffic cop. In the grand scheme of things, handling target database account information is a necessary but relative simple task of the MDM. The only things that has held back development of the mega-database manager have been time and money. If anyone out there has the money, I'll be happy the find the time... -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
|
From: Aleksey K. <kar...@cm...> - 2004-09-24 18:46:17
|
Hi! "Jim Starkey" <ja...@ne...> wrote in message news:415...@ne...... > > > This question has been around longer than Interbase. The great unwritten > component is traditionally called the mega-database manager. Why unwritten ? I thought there are lots of Mega Database Managers on the market. Most "big" DBMS have such capability not counting separate products. > The MDM is a provider (using Vulcan terminology) in which virtual > databases are defined from a number of physical databases. The MDM > manages virtual metadata, decomposes queries to underlaying databases, > optimizes semi-joins, and generally acts as traffic cop. In the grand > scheme of things, handling target database account information is a > necessary but relative simple task of the MDM. > > The only things that has held back development of the mega-database > manager have been time and money. If anyone out there has the money, I'll > be happy the find the time... What's the difference between performing a join (for example) using two tables in the single database or from the separate database files on the same Firebird server ? Two tables are just objects loaded in server memory at some point. One difference is 2PC protocol because different databases have their separate transaction models (own transaction log / back record version chain). But 2PC isn't worth considering as requiring too much money (and time) to implement ... Regards, Aleksey Karyakin > -- > > Jim Starkey > Netfrastructure, Inc. > 978 526-1376 > |
|
From: <hv...@us...> - 2004-09-26 12:29:55
|
> What's the difference between performing a join (for example) using two
> tables in the single database or from the separate database files on the
> same Firebird server ? Two tables are just objects loaded in server memory
> at some point.
Agreed, fully.
> One difference is 2PC protocol because different databases have their
> separate transaction models (own transaction log / back record version
> chain). But 2PC isn't worth considering as requiring too much money (and
> time) to implement ...
2PC already implemented in IB\FB.
Regards,
Vlad
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X