What if SET SESSION AUTHORIZATION could also accept a password so that non
superusers could switch to a different user? How difficult would this be?
One nice side benefit to this would be that you could effectively connect as
many users with Apache::DBI under mod perl without having an open connection
for every user.
Chris
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org) 14 1471
Chris Ochs wrote: What if SET SESSION AUTHORIZATION could also accept a password so that non superusers could switch to a different user? How difficult would this be?
Well, the password would go over the wire unencrypted, causing a
security problem.
--
Bruce Momjian | http://candle.pha.pa.us pg***@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Chris Ochs wrote: What if SET SESSION AUTHORIZATION could also accept a password so that non superusers could switch to a different user? How difficult would this be?
Well, the password would go over the wire unencrypted, causing a
security problem.
--
Bruce Momjian | http://candle.pha.pa.us pg***@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Bruce Momjian <pg***@candle.pha.pa.us> wrote: Chris Ochs wrote: What if SET SESSION AUTHORIZATION could also accept a password so that non superusers could switch to a different user? How difficult would this be?
Well, the password would go over the wire unencrypted, causing a security problem.
Only if encrypted transport is not enabled. With encrypted transport, it would
be as secure as anything else, right?
Perhaps, it could only be available if transmission encryption is enabled? Then
again, there's a certain amount of "only the user can shoot his own foot" that
has to be accepted ...
Just thinking out loud ...
--
Bill Moran
Potential Technologies http://www.potentialtech.com
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Bruce Momjian <pg***@candle.pha.pa.us> wrote: Chris Ochs wrote: What if SET SESSION AUTHORIZATION could also accept a password so that non superusers could switch to a different user? How difficult would this be?
Well, the password would go over the wire unencrypted, causing a security problem.
Only if encrypted transport is not enabled. With encrypted transport, it would
be as secure as anything else, right?
Perhaps, it could only be available if transmission encryption is enabled? Then
again, there's a certain amount of "only the user can shoot his own foot" that
has to be accepted ...
Just thinking out loud ...
--
Bill Moran
Potential Technologies http://www.potentialtech.com
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Bill Moran wrote: Bruce Momjian <pg***@candle.pha.pa.us> wrote:
Chris Ochs wrote: What if SET SESSION AUTHORIZATION could also accept a password so that non superusers could switch to a different user? How difficult would this be?
Well, the password would go over the wire unencrypted, causing a security problem.
Only if encrypted transport is not enabled. With encrypted transport, it would be as secure as anything else, right?
Perhaps, it could only be available if transmission encryption is enabled? Then again, there's a certain amount of "only the user can shoot his own foot" that has to be accepted ...
Just thinking out loud ...
Yes, if you use SSH it is secure, but do we want clauses that are only
useful in SSH mode?
--
Bruce Momjian | http://candle.pha.pa.us pg***@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Bill Moran wrote: Bruce Momjian <pg***@candle.pha.pa.us> wrote:
Chris Ochs wrote: What if SET SESSION AUTHORIZATION could also accept a password so that non superusers could switch to a different user? How difficult would this be?
Well, the password would go over the wire unencrypted, causing a security problem.
Only if encrypted transport is not enabled. With encrypted transport, it would be as secure as anything else, right?
Perhaps, it could only be available if transmission encryption is enabled? Then again, there's a certain amount of "only the user can shoot his own foot" that has to be accepted ...
Just thinking out loud ...
Yes, if you use SSH it is secure, but do we want clauses that are only
useful in SSH mode?
--
Bruce Momjian | http://candle.pha.pa.us pg***@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
As much as I hate to say it, if it would be insecure when not using ssl,
this is a feature that people would definitely use insecurely and one day it
would be labeled as a 'security hole' in postgresql.
Chris
----- Original Message -----
From: "Bill Moran" <wm****@potentialtech.com>
To: "Bruce Momjian" <pg***@candle.pha.pa.us>
Cc: <ch***@paymentonline.com>; <pg***********@postgresql.org>
Sent: Tuesday, June 15, 2004 8:13 AM
Subject: Re: [GENERAL] Feature idea Bruce Momjian <pg***@candle.pha.pa.us> wrote:
Chris Ochs wrote: What if SET SESSION AUTHORIZATION could also accept a password so that
non superusers could switch to a different user? How difficult would this
be? Well, the password would go over the wire unencrypted, causing a security problem. Only if encrypted transport is not enabled. With encrypted transport, it
would be as secure as anything else, right?
Perhaps, it could only be available if transmission encryption is enabled?
Then again, there's a certain amount of "only the user can shoot his own foot"
that has to be accepted ...
Just thinking out loud ...
-- Bill Moran Potential Technologies http://www.potentialtech.com
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
As much as I hate to say it, if it would be insecure when not using ssl,
this is a feature that people would definitely use insecurely and one day it
would be labeled as a 'security hole' in postgresql.
Chris
----- Original Message -----
From: "Bill Moran" <wm****@potentialtech.com>
To: "Bruce Momjian" <pg***@candle.pha.pa.us>
Cc: <ch***@paymentonline.com>; <pg***********@postgresql.org>
Sent: Tuesday, June 15, 2004 8:13 AM
Subject: Re: [GENERAL] Feature idea Bruce Momjian <pg***@candle.pha.pa.us> wrote:
Chris Ochs wrote: What if SET SESSION AUTHORIZATION could also accept a password so that
non superusers could switch to a different user? How difficult would this
be? Well, the password would go over the wire unencrypted, causing a security problem. Only if encrypted transport is not enabled. With encrypted transport, it
would be as secure as anything else, right?
Perhaps, it could only be available if transmission encryption is enabled?
Then again, there's a certain amount of "only the user can shoot his own foot"
that has to be accepted ...
Just thinking out loud ...
-- Bill Moran Potential Technologies http://www.potentialtech.com
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Bruce Momjian <pg***@candle.pha.pa.us> wrote: Bill Moran wrote: Bruce Momjian <pg***@candle.pha.pa.us> wrote:
Chris Ochs wrote: > > What if SET SESSION AUTHORIZATION could also accept a password so that non > superusers could switch to a different user? How difficult would this be?
Well, the password would go over the wire unencrypted, causing a security problem.
Only if encrypted transport is not enabled. With encrypted transport, it would be as secure as anything else, right?
Perhaps, it could only be available if transmission encryption is enabled? Then again, there's a certain amount of "only the user can shoot his own foot" that has to be accepted ...
Just thinking out loud ...
Yes, if you use SSH it is secure, but do we want clauses that are only useful in SSH mode?
Not to start an argument, but you could reverse that logic and say "Do you want
to hurt the smart, ssl users by not including helpful functionality that could
be dangerous to uneducated non-ssl users?"
IMHO, it really depends on the design philosophy that PostgreSQL follows. I'm
familiar with the strong push for stability, and I approve. But I'm not as
sure I have a feel for what developers think about this kind of thing.
If you made it a compile-time option, or made it disabled by default and
requires a special setting in postgresql.conf to enable. Would that be secure?
Not really, as stupid users would still enable it without understanding, and
there's always the possibility that a some packager would build it with
dangerous settings and distribute it widely.
(As a side note, I seem to remember a program that had a --shoot-my-own-foot
option to ./configure ... but I can't remember what it was ...)
So, the question becomes one of design philosophy (at least, I'm basing this on
the concept that actual implementation would not be too hard, correct me if I'm
wrong)
--
Bill Moran
Potential Technologies http://www.potentialtech.com
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Bruce Momjian <pg***@candle.pha.pa.us> wrote: Bill Moran wrote: Bruce Momjian <pg***@candle.pha.pa.us> wrote:
Chris Ochs wrote: > > What if SET SESSION AUTHORIZATION could also accept a password so that non > superusers could switch to a different user? How difficult would this be?
Well, the password would go over the wire unencrypted, causing a security problem.
Only if encrypted transport is not enabled. With encrypted transport, it would be as secure as anything else, right?
Perhaps, it could only be available if transmission encryption is enabled? Then again, there's a certain amount of "only the user can shoot his own foot" that has to be accepted ...
Just thinking out loud ...
Yes, if you use SSH it is secure, but do we want clauses that are only useful in SSH mode?
Not to start an argument, but you could reverse that logic and say "Do you want
to hurt the smart, ssl users by not including helpful functionality that could
be dangerous to uneducated non-ssl users?"
IMHO, it really depends on the design philosophy that PostgreSQL follows. I'm
familiar with the strong push for stability, and I approve. But I'm not as
sure I have a feel for what developers think about this kind of thing.
If you made it a compile-time option, or made it disabled by default and
requires a special setting in postgresql.conf to enable. Would that be secure?
Not really, as stupid users would still enable it without understanding, and
there's always the possibility that a some packager would build it with
dangerous settings and distribute it widely.
(As a side note, I seem to remember a program that had a --shoot-my-own-foot
option to ./configure ... but I can't remember what it was ...)
So, the question becomes one of design philosophy (at least, I'm basing this on
the concept that actual implementation would not be too hard, correct me if I'm
wrong)
--
Bill Moran
Potential Technologies http://www.potentialtech.com
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Bill Moran wrote: Not to start an argument, but you could reverse that logic and say "Do you want to hurt the smart, ssl users by not including helpful functionality that could be dangerous to uneducated non-ssl users?"
IMHO, it really depends on the design philosophy that PostgreSQL follows. I'm familiar with the strong push for stability, and I approve. But I'm not as sure I have a feel for what developers think about this kind of thing.
If you made it a compile-time option, or made it disabled by default and requires a special setting in postgresql.conf to enable. Would that be secure? Not really, as stupid users would still enable it without understanding, and there's always the possibility that a some packager would build it with dangerous settings and distribute it widely.
(As a side note, I seem to remember a program that had a --shoot-my-own-foot option to ./configure ... but I can't remember what it was ...)
So, the question becomes one of design philosophy (at least, I'm basing this on the concept that actual implementation would not be too hard, correct me if I'm wrong)
You are correct. The question is whether it is worth adding that level
of complexity into the system --- in the past, we have decided it isn't.
We have the $HOME/.pgpass file to store username/password combinations
that is probably best, though it works only with libpq-based interfaces.
--
Bruce Momjian | http://candle.pha.pa.us pg***@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly
Bill Moran wrote: Not to start an argument, but you could reverse that logic and say "Do you want to hurt the smart, ssl users by not including helpful functionality that could be dangerous to uneducated non-ssl users?"
IMHO, it really depends on the design philosophy that PostgreSQL follows. I'm familiar with the strong push for stability, and I approve. But I'm not as sure I have a feel for what developers think about this kind of thing.
If you made it a compile-time option, or made it disabled by default and requires a special setting in postgresql.conf to enable. Would that be secure? Not really, as stupid users would still enable it without understanding, and there's always the possibility that a some packager would build it with dangerous settings and distribute it widely.
(As a side note, I seem to remember a program that had a --shoot-my-own-foot option to ./configure ... but I can't remember what it was ...)
So, the question becomes one of design philosophy (at least, I'm basing this on the concept that actual implementation would not be too hard, correct me if I'm wrong)
You are correct. The question is whether it is worth adding that level
of complexity into the system --- in the past, we have decided it isn't.
We have the $HOME/.pgpass file to store username/password combinations
that is probably best, though it works only with libpq-based interfaces.
--
Bruce Momjian | http://candle.pha.pa.us pg***@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly
On Tue, Jun 15, 2004 at 11:43:08AM -0400, Bill Moran wrote: Bruce Momjian <pg***@candle.pha.pa.us> wrote: Bill Moran wrote: Bruce Momjian <pg***@candle.pha.pa.us> wrote: > Chris Ochs wrote: > > What if SET SESSION AUTHORIZATION could also accept a password so that non > > superusers could switch to a different user? How difficult would this be? Not to start an argument, but you could reverse that logic and say "Do you want to hurt the smart, ssl users by not including helpful functionality that could be dangerous to uneducated non-ssl users?" ... So, the question becomes one of design philosophy (at least, I'm basing this on the concept that actual implementation would not be too hard, correct me if I'm wrong)
How about each user can set up a list of authorised users that
are allowed to switch to their username.
This would then follow the same model as authorized_keys/.rhosts in
ssh/rsh
user1 could then call something like GRANT SESSION TO user2
which would allow user2 to switch to user1
Would it also be possible to restrict the grants when doing this?
e.g. GRANT SESSION SELECT ON DATABASE foo TO user2 GRANT SESSION UPDATE ON TABLE bar TO user2
Which would allow updates to be made to table bar after the switch.
-Mark
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
On Tue, Jun 15, 2004 at 11:43:08AM -0400, Bill Moran wrote: Bruce Momjian <pg***@candle.pha.pa.us> wrote: Bill Moran wrote: Bruce Momjian <pg***@candle.pha.pa.us> wrote: > Chris Ochs wrote: > > What if SET SESSION AUTHORIZATION could also accept a password so that non > > superusers could switch to a different user? How difficult would this be? Not to start an argument, but you could reverse that logic and say "Do you want to hurt the smart, ssl users by not including helpful functionality that could be dangerous to uneducated non-ssl users?" ... So, the question becomes one of design philosophy (at least, I'm basing this on the concept that actual implementation would not be too hard, correct me if I'm wrong)
How about each user can set up a list of authorised users that
are allowed to switch to their username.
This would then follow the same model as authorized_keys/.rhosts in
ssh/rsh
user1 could then call something like GRANT SESSION TO user2
which would allow user2 to switch to user1
Would it also be possible to restrict the grants when doing this?
e.g. GRANT SESSION SELECT ON DATABASE foo TO user2 GRANT SESSION UPDATE ON TABLE bar TO user2
Which would allow updates to be made to table bar after the switch.
-Mark
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jordan Rastrick |
last post by:
First, a disclaimer. I am a second year Maths and Computer Science
undergraduate, and this is my first time ever on Usenet (I guess I'm
part of the http generation). On top of that, I have been...
|
by: Russell Mangel |
last post by:
I was thinking about what IDE feature I would want the most in the next
version of VC++?
I would definately ask for the C# feature: #region / #endregion.
In my opinion this feature was a...
|
by: anony |
last post by:
Maybe this feature is already out there.
I guess you could write triggers to do some of this.
Often when designing a database I add a start_date and end_date column
to the table. The start_date...
|
by: Raymond Hettinger |
last post by:
Proposal
--------
I am gathering data to evaluate a request for an alternate version of
itertools.izip() with a None fill-in feature like that for the built-in
map() function:
>>> map(None,...
|
by: Raymond Hettinger |
last post by:
I am evaluating a request for an alternate version of itertools.izip()
that has a None fill-in feature like the built-in map function:
>>> map(None, 'abc', '12345') # demonstrate map's None...
|
by: toolmaster |
last post by:
Since many of the modern computer languages have built-in namespace
features, I can't understand why not add this feature into standard C.
I've heard many people complain of the lacking of...
|
by: samjnaa |
last post by:
This is like the previous one. Please check for sanity and approve for
posting at python-dev.
I would like to have something like "option base" in Visual Basic.
IIRC it used to allow me to...
|
by: samjnaa |
last post by:
Please check for sanity and approve for posting at python-dev.
In Visual Basic there is the keyword "with" which allows an object-
name to be declared as governing the following statements. For...
|
by: Luke R |
last post by:
One thing i used to use alot in vb6 was that tiny little button in the
bottom left of the code window which allowed you to view either the whole
code file, or just the function/sub you are currenly...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |