[freetds] How to specify uid and pwd in odbc.ini?

[Михаил Гаврилов]

Hi!

Any updates here??

I need also to specify login and password for ODBC connection.
It needed for using with MaridDB CONNECT engine for easy proxy MS SQL
to MariaDB.




--
Best Regards,
Mike Gavrilov.

[Frediano Ziglio]

No way, for security reason.

Frediano

Post by Михаил Гаврилов
Hi!
Any updates here??
I need also to specify login and password for ODBC connection.
It needed for using with MaridDB CONNECT engine for easy proxy MS SQL
to MariaDB.
--
Best Regards,
Mike Gavrilov.
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

[unknown]

I really do not understand is it safer to write when creating each table
username and password than store in in one place in odbc.ini on
server???

CREATE TABLE ttlog ENGINE=CONNECT table_type=ODBC tabname='ttlog'
CONNECTION='DSN=SQL_DW;UID=lnmp;PWD=lnmp'

And will be really nightmare if lnmp password changed. :(

Post by Frediano Ziglio
No way, for security reason.
Frediano

Post by Михаил Гаврилов
Hi!
Any updates here??
I need also to specify login and password for ODBC connection.
It needed for using with MaridDB CONNECT engine for easy proxy MS SQL
to MariaDB.
--
Best Regards,
Mike Gavrilov.
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

[Михаил Гаврилов]

Frediano, I may not expect to this feature? :(




--
Best Regards,
Mike Gavrilov.

Post by unknown
I really do not understand is it safer to write when creating each table
username and password than store in in one place in odbc.ini on
server???
CREATE TABLE ttlog ENGINE=CONNECT table_type=ODBC tabname='ttlog'
CONNECTION='DSN=SQL_DW;UID=lnmp;PWD=lnmp'
And will be really nightmare if lnmp password changed. :(

Post by Frediano Ziglio
No way, for security reason.
Frediano

Post by Михаил Гаврилов
Hi!
Any updates here??
I need also to specify login and password for ODBC connection.
It needed for using with MaridDB CONNECT engine for easy proxy MS SQL
to MariaDB.
--
Best Regards,
Mike Gavrilov.
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

[James K. Lowden]

On Tue, 19 Nov 2013 15:45:53 +0000

Post by unknown
I really do not understand is it safer to write when creating each
table username and password than store in in one place in odbc.ini on
server???
CREATE TABLE ttlog ENGINE=CONNECT table_type=ODBC tabname='ttlog'
CONNECTION='DSN=SQL_DW;UID=lnmp;PWD=lnmp'
And will be really nightmare if lnmp password changed. :(

(It is helpful to readers of the archive if you don't top-quote.)

We don't read passwords from odbc.ini for security reasons. We
recommend that people who want passwordless connections use Kerberos or
similar. FreeTDS supports it for all servers and clients, as far as
I'm aware.

If you don't need security, you could set up an account with no
password (or a known one, and hard-code it).

If you want a little security, the kind that will discourage your
grandmother, keep your passwords in a file or environment variable. I
used to keep mine in ~/.netrc, and use awk to parse out the bits.

HTH.

--jkl

[Михаил Гаврилов]

Post by James K. Lowden
(It is helpful to readers of the archive if you don't top-quote.)
We don't read passwords from odbc.ini for security reasons. We
recommend that people who want passwordless connections use Kerberos or
similar. FreeTDS supports it for all servers and clients, as far as
I'm aware.
If you don't need security, you could set up an account with no
password (or a known one, and hard-code it).
If you want a little security, the kind that will discourage your
grandmother, keep your passwords in a file or environment variable. I
used to keep mine in ~/.netrc, and use awk to parse out the bits.
HTH.

Excuse me, but why do not you leave the choice for developers , where
to store the passwords from the database connection . For my web
application I store passwords in clear text in the config file on the
server and as time has shown it is more than enough. But now we are
not talking about it. I want to use the latest feature of MariaDB
which allows you to access any database tables having the ODBC driver
as native tables. And I believe more secure in this case is to store
passwords in odbc.ini than talking passwords to everyone who creates
their tables. About using Kerberos. I'm not admin MS SQL and could not
affect to admins of MS SQL. I have been working through the usual SQL
account that I was given. I came here because I expected on your help,
but instead got a story that shoot in the leg is hurt, I know about
this, let me leave the choice, in my case for connect to MS SQL from
MariaDB ideal is storing passwords in odbc.ini. I also can't modify
MariaDB to that use ~/.netrc for store passwords. :(

sorry for my english.




--
Best Regards,
Mike Gavrilov.

[James K. Lowden]

On Tue, 26 Nov 2013 04:28:45 +0600

I came here because I expected on your help, but instead got a story
that shoot in the leg is hurt, I know about this, let me leave the
choice, in my case for connect to MS SQL from MariaDB ideal is
storing passwords in odbc.ini.

You *are* getting help. I explained the features, and offered a few
alternatives. Or did you think it was my job to foresee your desires
before you wrote?

As far as I know, Microsoft's driver doesn't read passwords from
odbc.ini either. Using odbc.ini that way would be bad practice and bad
design.

It's not a matter of choosing not to help. It's a matter of choosing
what features to devote our time to. We decided against bothering to
parse passwords from odbc.ini keeping them there creates more problems
than it solves.

An odbc.ini entry describes a server: the TDS version it supports, the
name of the host, the port. It does not describe a user. If you add
the "default user" or somesuch goes in odbc.ini, it opens Pandora's
Box. What to do about the second user? What to do about *any* user
who forgets to provide credentials?

Providing bad defaults leads to unhappy experiences. Better not to do
it.

When you think about it, the situations for which keeping user
credentials in odbc.ini works well are quite special. Yours may be
such a case; I don't know. I do know that special cases --
particularly when contraindicated by common cases -- belong in
the application, not the library.

--jkl