ipcclean in 8.1 broken?

No-one has a comment on this?

Christopher Kings-Lynne wrote:

Am Dienstag, 28. Februar 2006 07:42 schrieb Christopher Kings-Lynne:

I just tried using ipcclean in 8.1.3. It doesn't work when I su to the
pgsql user. This part of the script:

if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ]

Always fails because even tho $USER is set to 'pgsql' when su'ed,
$LOGNAME is still root.

This is on FreeBSD 4.9

It seems to work on Linux; apparently there are different behaviors of su. Do
you have a suggestion for resolving this?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

# peter_e@gmx.net / 2006-03-01 12:49:13 +0100:

Am Dienstag, 28. Februar 2006 07:42 schrieb Christopher Kings-Lynne:

I just tried using ipcclean in 8.1.3. It doesn't work when I su to the
pgsql user. This part of the script:

if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ]

Always fails because even tho $USER is set to 'pgsql' when su'ed,
$LOGNAME is still root.

This is on FreeBSD 4.9

It seems to work on Linux; apparently there are different behaviors of su. Do
you have a suggestion for resolving this?

use "su -l"? this is on FreeBSD 6:

By default, the environment is unmodified with the exception of USER,
HOME, and SHELL.
...
-l Simulate a full login. The environment is discarded except for
HOME, SHELL, PATH, TERM, and USER. HOME and SHELL are modified
as above. USER is set to the target login. PATH is set to
``/bin:/usr/bin''. TERM is imported from your current environ-
ment.

smradoch@neuhauser ~ 1001:0 > echo $USER $LOGNAME
smradoch smradoch
smradoch@neuhauser ~ 1002:0 > su -l
Password:
neuhauser# echo $USER $LOGNAME
root root
neuhauser# logout
smradoch@neuhauser ~ 1003:0 > su
Password:
You have mail.
neuhauser# echo $USER $LOGNAME
smradoch smradoch
neuhauser# exit
smradoch@neuhauser ~ 1004:0 > uname -srm
FreeBSD 6.1-PRERELEASE amd64

su (coreutils) 4.5.3 on RHEL3 behaves exactly the same.

--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991

I wonder if there could be a potential problem with using this approach
-
checking on $USER == root.

Although it is a common practice, I think a superuser does not have to
be root.
If I'm right here, a better technique could be executing `id`.

Mike

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Peter
Eisentraut
Sent: Wednesday, March 01, 2006 6:49 AM
To: pgsql-hackers@postgresql.org
Cc: Christopher Kings-Lynne
Subject: Re: [HACKERS] ipcclean in 8.1 broken?

Am Dienstag, 28. Februar 2006 07:42 schrieb Christopher Kings-Lynne:

I just tried using ipcclean in 8.1.3. It doesn't work when I su to

the

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

No-one has a comment on this?

ipcclean has never been much more than beta-quality software; it doesn't
pretend to be very portable.

Having said that, I think the anti-root check is bogus. It was probably
added in a fit of "let's make sure nobody tries to admin PG as root",
but I don't see why that applies to ipcclean. The only thing that
really matters is whether the subsequent id/whoami lookup comes up with
the proper user id. I'd be inclined to do the id lookup and then bomb
out if it came up with 0 (just to ensure that no one accidentally blows
away really-important shared memory segments).

regards, tom lane

if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ]

Always fails because even tho $USER is set to 'pgsql' when su'ed,
$LOGNAME is still root.

This is on FreeBSD 4.9

It seems to work on Linux; apparently there are different behaviors of su. Do
you have a suggestion for resolving this?

Well all I did to fix it on FreeBSD was to remove the '-o "$LOGNAME" =
'root'' bit...

Chris

I wonder if there could be a potential problem with using this approach
-
checking on $USER == root.

Although it is a common practice, I think a superuser does not have to
be root.

Yes, like the 'toor' account in FreeBSD... (disabled by default though)

Chris

Christopher Kings-Lynne wrote:

I wonder if there could be a potential problem with using this approach
-
checking on $USER == root.

Although it is a common practice, I think a superuser does not have to
be root.

Yes, like the 'toor' account in FreeBSD... (disabled by default though)

Might be better to check if uid == 0, however there are some traps here
too as the most convenient methd ('id -u') is not support everywhere
(e.g Solaris 8). I think I used awk or sed on the plain old 'id' output
last time something like this came up.

Cheers

Mark

I have a question about how to display query time of postgres. I found
this
postgres [ -A { 0 | 1 } ] [ -B buffers ] [ -c name=value ] [ -d
debug-level ]
[ -D datadir ] [ -e ] [ -E ] [ -f { s | i | n | m | h } ] [ -F ]
[ -i ] [ -L ] [ -N ] [ -o file-name ] [ -O ] [ -P ]
[ -s | -t { pa | pl | ex } ] [ -S sort_mem ] [ -W num ] database

adding -s will print the statistis and time. But I have no idea how to call
this using postmaster -o option. Anyone give me a hint? Thanks.

-John

On Wed, Mar 01, 2006 at 10:13:02PM -0600, John wrote:

adding -s will print the statistis and time. But I have no idea how to call
this using postmaster -o option. Anyone give me a hint? Thanks.

postmaster -o -s [ other options ]

Or you could enable log_statement_stats in postgresql.conf.

--
Michael Fuhr

Christopher Kings-Lynne wrote:

if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ]

Always fails because even tho $USER is set to 'pgsql' when su'ed,
$LOGNAME is still root.

This is on FreeBSD 4.9

It seems to work on Linux; apparently there are different behaviors of su. Do
you have a suggestion for resolving this?

Well all I did to fix it on FreeBSD was to remove the '-o "$LOGNAME" =
'root'' bit...

I applied the attached patch to CVS HEAD and 8.1.X. It looks at LOGNAME
only if USER is not set.

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I applied the attached patch to CVS HEAD and 8.1.X. It looks at LOGNAME
only if USER is not set.

! if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ]

! # only check $LOGNAME if $USER is not set
! if [ "$USER" = 'root' -o \( ! "$USER" -a "$LOGNAME" = 'root' \) ]

Bruce, this patch isn't going to fix anything.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I applied the attached patch to CVS HEAD and 8.1.X. It looks at LOGNAME
only if USER is not set.

! if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ]

! # only check $LOGNAME if $USER is not set
! if [ "$USER" = 'root' -o \( ! "$USER" -a "$LOGNAME" = 'root' \) ]

Bruce, this patch isn't going to fix anything.

Chris said he did:

Well all I did to fix it on FreeBSD was to remove the '-o "$LOGNAME" =
'root'' bit...

so I figured the patch would help, no?

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Chris said he did:

Well all I did to fix it on FreeBSD was to remove the '-o "$LOGNAME" =
'root'' bit...

so I figured the patch would help, no?

No, because there's no good reason to suppose that $USER wouldn't be set.

I think we should remove that entire code block, and instead check for a
zero value of EffectiveUser after doing the id bit.

(I'm not finding it right now, but I'm pretty sure that the SUS
specifies that numeric userid == 0 for superuser, whereas "root" is not
required to be the name, so this would be more correct anyway.)

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Chris said he did:

Well all I did to fix it on FreeBSD was to remove the '-o "$LOGNAME" =
'root'' bit...

so I figured the patch would help, no?

No, because there's no good reason to suppose that $USER wouldn't be set.

But if USER is set, why check LOGNAME?

I think we should remove that entire code block, and instead check for a
zero value of EffectiveUser after doing the id bit.

(I'm not finding it right now, but I'm pretty sure that the SUS
specifies that numeric userid == 0 for superuser, whereas "root" is not
required to be the name, so this would be more correct anyway.)

Can we assume 'id' is on all unix systems?

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

(I'm not finding it right now, but I'm pretty sure that the SUS
specifies that numeric userid == 0 for superuser, whereas "root" is not
required to be the name, so this would be more correct anyway.)

Can we assume 'id' is on all unix systems?

What's your point? The script fails anyway if that bit doesn't work.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

(I'm not finding it right now, but I'm pretty sure that the SUS
specifies that numeric userid == 0 for superuser, whereas "root" is not
required to be the name, so this would be more correct anyway.)

Can we assume 'id' is on all unix systems?

What's your point? The script fails anyway if that bit doesn't work.

Is 'id' better than what we have now if 'id' isn't widely supported?

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

On Fri, Mar 03, 2006 at 01:00:59PM -0500, Bruce Momjian wrote:

Tom Lane wrote:

(I'm not finding it right now, but I'm pretty sure that the SUS
specifies that numeric userid == 0 for superuser, whereas "root" is not
required to be the name, so this would be more correct anyway.)

The Rationale (XRAT) Definitions section says for "Superuser":

This concept, with great historical significance to UNIX system
users, has been replaced with the notion of appropriate privileges.

An excerpt from the definition of "Appropriate Privileges" is

For many historical implementations of the UNIX system, the
presence of the term "appropriate privileges" in POSIX.1 may be
understood as a synonym for "superuser" (UID 0). However, other
systems have emerged where this is not the case and each discrete
controllable action has appropriate privileges associated with
it. Because this mechanism is implementation-defined, it must
be described in the conformance document.

(I'd post links but people elsewhere haved bitched about doing that
because the documents are supposed to require registration to read.
If that's true then it seems silly that they're available to anybody
who knows the URL.)

Can we assume 'id' is on all unix systems?

It's defined in Shell and Utilities (XCU). If the system doesn't
have it then one must wonder what else the system is missing.

--
Michael Fuhr

Bruce Momjian wrote:

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

(I'm not finding it right now, but I'm pretty sure that the SUS
specifies that numeric userid == 0 for superuser, whereas "root" is
not
required to be the name, so this would be more correct anyway.)

Can we assume 'id' is on all unix systems?

What's your point? The script fails anyway if that bit doesn't work.

Is 'id' better than what we have now if 'id' isn't widely supported?

I don't think this is really a question of portability. The variables $USER
and $LOGNAME are not always set to the current (effective) user, e.g. on
linux. That's Chris' current problem, I think. Just compare the difference
of using "su" with and without the "-l" argument:

$ su
# echo $LOGNAME ; echo $USER
mip
mip
# exit
$ su -l
# echo $LOGNAME ; echo $USER
root
root
#

Of course, if you just want to question the use of "id", that's a different
story.

Best Regards,
Michael Paesold

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

What's your point? The script fails anyway if that bit doesn't work.

Is 'id' better than what we have now if 'id' isn't widely supported?

I'm repeating myself, but: what's your point? 'id' exists on Linux,
and the script fails (in the worst possible way, ie, might remove
inappropriate shmem segments) on all other platforms if it's unable
to detect the correct EffectiveUser. I would argue that checking for a
numeric, nonzero EffectiveUser is going to make it safer not less so.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

What's your point? The script fails anyway if that bit doesn't work.

Is 'id' better than what we have now if 'id' isn't widely supported?

I'm repeating myself, but: what's your point? 'id' exists on Linux,
and the script fails (in the worst possible way, ie, might remove
inappropriate shmem segments) on all other platforms if it's unable
to detect the correct EffectiveUser. I would argue that checking for a
numeric, nonzero EffectiveUser is going to make it safer not less so.

If it can be done more reliably than what we do not. We support much
more than Linix, and I have not seen anyway say 'id' is available on all
platforms. We can try 'id' if it exists and fall back if it doesn't.

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

What's your point? The script fails anyway if that bit doesn't work.

Is 'id' better than what we have now if 'id' isn't widely supported?

I'm repeating myself, but: what's your point? 'id' exists on Linux,
and the script fails (in the worst possible way, ie, might remove
inappropriate shmem segments) on all other platforms if it's unable
to detect the correct EffectiveUser. I would argue that checking for a
numeric, nonzero EffectiveUser is going to make it safer not less so.

If it can be done more reliably than what we do not. We support much
more than Linix, and I have not seen anyway say 'id' is available on all
platforms. We can try 'id' if it exists and fall back if it doesn't.

perl -e 'exit $> != 0 ;'

succeeds iff your effective uid is not 0.

or we could revive pg_id.

(for the humor impaired, no, I am not serious.)

cheers

andrew