Thread

Re: Password sub-process ...

Marc G. Fournier <scrappy@hub.org> — 2002-07-30T14:55:55Z

On Tue, 30 Jul 2002, Andrew Sullivan wrote:

> On Tue, Jul 30, 2002 at 12:43:52AM -0300, Marc G. Fournier wrote:
>
> > since as soon as there are two 'bruce' users, only one can have a password
>
> I guess I don't understand why that's a problem.  I mean, if you're
> authenticating users, how can you have two with the same name?  It's
> just like UNIX usernames, to my mind: they have to be unique on the
> system, no?

I think that is the problem with everyone's "thinking" ... they are only
dealing with 'small servers', where it only has a couple of databases ...
I'm currently running a server with >100 domains on it, each one with *at
least* one database ... each one of those domains, in reality, *could*
have a user 'bruce' ...

note that I run virtual machines ... so each one fo those 'domains' has
their own password files, so I can't say to 'client A' that 'client B'
already has user 'bruce', so you can't use it, even though its unique to
your system ...

And, I don't want to run 100 pgsql instances on the server, since either
I'd have to have one helluva lot of RAM dedicated to PgSQL, or have little
tiny shared memory segments available to each ...

actually, let's add onto that ... let's say every one of those 100 pgsql
databases is accessed by PHPPgAdmin, through the web ... so, with a
'common password' amongst all the various 'bruce's, I could, in theory, go
to any other domain's PHPPgAdmin, login and see their databases (major
security problem) ... the way it was before, I could setup a password file
that contained a different password for each of those domains, so that
bruce on domain 1 couldn't access domain 2's databases ... or vice versa
...

I've CC'd this back into the list, mainly because I think others might be
'thinking within the box' on this :(

Re: Password sub-process ...

Thomas Lockhart <lockhart@fourpalms.org> — 2002-07-30T15:19:29Z

> ... amongst all the various 'bruce's...

Hmm. The "Monty Python scenario"? :)

                  - Thomas

Re: Password sub-process ...

Joe Conway <mail@joeconway.com> — 2002-07-30T15:23:15Z

Marc G. Fournier wrote:
> I think that is the problem with everyone's "thinking" ... they are only
> dealing with 'small servers', where it only has a couple of databases ...
> I'm currently running a server with >100 domains on it, each one with *at
> least* one database ... each one of those domains, in reality, *could*
> have a user 'bruce' ...
> 
> note that I run virtual machines ... so each one fo those 'domains' has
> their own password files, so I can't say to 'client A' that 'client B'
> already has user 'bruce', so you can't use it, even though its unique to
> your system ...
> 
> And, I don't want to run 100 pgsql instances on the server, since either
> I'd have to have one helluva lot of RAM dedicated to PgSQL, or have little
> tiny shared memory segments available to each ...
> 
> actually, let's add onto that ... let's say every one of those 100 pgsql
> databases is accessed by PHPPgAdmin, through the web ... so, with a
> 'common password' amongst all the various 'bruce's, I could, in theory, go
> to any other domain's PHPPgAdmin, login and see their databases (major
> security problem) ... the way it was before, I could setup a password file
> that contained a different password for each of those domains, so that
> bruce on domain 1 couldn't access domain 2's databases ... or vice versa
> ...
> 
> I've CC'd this back into the list, mainly because I think others might be
> 'thinking within the box' on this :(

How hard would it be to do something like this:

1. Add a column called usedatid to pg_shadow. This would contain an 
array of database oids to which a user is bound. Use the value 0 to mean 
"all databases".

2. Remove unique index on usename (we always know which database a user 
is logging in to, don't we?). Change unique index on usesysid to be over 
both usesysid and usedatid.

3. Add sufficient grammer to support specifying a specific database when 
creating a user. Default to all databases for BC. Add ability to bind to 
additional databases in ALTER USER.

Just trying to think outside the box ;-)

Joe

Re: Password sub-process ...

Neil Conway <nconway@klamath.dyndns.org> — 2002-07-30T15:23:17Z

On Tue, Jul 30, 2002 at 11:55:55AM -0300, Marc G. Fournier wrote:
> I think that is the problem with everyone's "thinking" ... they are only
> dealing with 'small servers', where it only has a couple of databases ...
> I'm currently running a server with >100 domains on it, each one with *at
> least* one database ... each one of those domains, in reality, *could*
> have a user 'bruce' ...

First off, I think the implementation of this functionality present in 7.2
was a big hack, and I'd rather not see it resurrected.

However, it would be useful to be able to do something like this -- how
about something like the following:

    - the auth system contains a list of 'auth domains' -- an identifier
      similar to a schema name

    - the combination of (domain, username) must be unique -- i.e. a
      username is unique within a domain

    - each database exists within a single domain; a domain can have 0,
      1, or many databases

    - by default, the system ships with a single auth domain; when a
      user is created, the admin can specify the domain in which the
      user exists, otherwise it defaults to the default domain

Anyway, just thinking out loud -- that may or may not make any sense...

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

Re: Password sub-process ...

Hannu Krosing <hannu@tm.ee> — 2002-07-30T16:31:14Z

On Tue, 2002-07-30 at 16:55, Marc G. Fournier wrote:
> On Tue, 30 Jul 2002, Andrew Sullivan wrote:
> 
> > On Tue, Jul 30, 2002 at 12:43:52AM -0300, Marc G. Fournier wrote:
> >
> > > since as soon as there are two 'bruce' users, only one can have a password
> >
> > I guess I don't understand why that's a problem.  I mean, if you're
> > authenticating users, how can you have two with the same name?  It's
> > just like UNIX usernames, to my mind: they have to be unique on the
> > system, no?
> 
> I think that is the problem with everyone's "thinking" ... they are only
> dealing with 'small servers', where it only has a couple of databases ...
> I'm currently running a server with >100 domains on it, each one with *at
> least* one database ... each one of those domains, in reality, *could*
> have a user 'bruce' ...
> 
> note that I run virtual machines ... so each one fo those 'domains' has
> their own password files, so I can't say to 'client A' that 'client B'
> already has user 'bruce', so you can't use it, even though its unique to
> your system ...

But if they are _really_ virtual machines then you can probably
distinguish them by IP as was discussed earlier.

Or you can declare each virtual machine to be its own "domain" and name
db users user@domain (or //domain/user if you are inclined that way ;).
both of these names are accepted by postgres as valid usernames.

I guess you must doing something like that with their e-mail addresses
already ;)

> And, I don't want to run 100 pgsql instances on the server, since either
> I'd have to have one helluva lot of RAM dedicated to PgSQL, or have little
> tiny shared memory segments available to each ...
> 
> actually, let's add onto that ... let's say every one of those 100 pgsql
> databases is accessed by PHPPgAdmin, through the web ... so, with a
> 'common password' amongst all the various 'bruce's, I could, in theory, go
> to any other domain's PHPPgAdmin, login and see their databases (major
> security problem) ...

Bugzilla resolves the problem of "many bruces" by having e-mail address
as a globally unique username.

> the way it was before, I could setup a password file
> that contained a different password for each of those domains, so that
> bruce on domain 1 couldn't access domain 2's databases ... or vice versa
> ...
> 
> I've CC'd this back into the list, mainly because I think others might be
> 'thinking within the box' on this :(

Otoh, thinking that distinguishing users by password is a good idea can
also be considered 'thinking within the box' by some ;)

--------------------
Hannu

Re: Password sub-process ...

Peter Eisentraut <peter_e@gmx.net> — 2002-07-30T21:42:00Z

Neil Conway writes:

> However, it would be useful to be able to do something like this -- how
> about something like the following:
>
>     - the auth system contains a list of 'auth domains' -- an identifier
>       similar to a schema name
>
>     - the combination of (domain, username) must be unique -- i.e. a
>       username is unique within a domain
>
>     - each database exists within a single domain; a domain can have 0,
>       1, or many databases
>
>     - by default, the system ships with a single auth domain; when a
>       user is created, the admin can specify the domain in which the
>       user exists, otherwise it defaults to the default domain
>
> Anyway, just thinking out loud -- that may or may not make any sense...

Actually, I was thinking just about the same thing.  Essentially you're
proposing virtual hosting, where "domain" is the same thing as a virtual
host URI.  Somewhere you'd need a configuration file that maps request
parameters (host and port, basically) to a domain (not sure if I'd use
that name, though).  I like it.

-- 
Peter Eisentraut   peter_e@gmx.net