Thread

ipcclean in 8.1 broken?

Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2006-02-28T06:42:22Z

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

Chris

Re: ipcclean in 8.1 broken?

Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2006-03-01T08:39:32Z

No-one has a comment on this?

Christopher Kings-Lynne wrote:
> 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
> 
> Chris
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly

Re: ipcclean in 8.1 broken?

Peter Eisentraut <peter_e@gmx.net> — 2006-03-01T11:49:13Z

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/

Re: ipcclean in 8.1 broken?

Roman Neuhauser <neuhauser@sigpipe.cz> — 2006-03-01T12:04:11Z

# 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

Re: ipcclean in 8.1 broken?

Tom Lane <tgl@sss.pgh.pa.us> — 2006-03-01T15:46:05Z

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

Re: ipcclean in 8.1 broken?

Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2006-03-02T01:27:17Z

>> 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

Re: ipcclean in 8.1 broken?

Bruce Momjian <pgman@candle.pha.pa.us> — 2006-03-03T16:54:58Z

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. +

Re: ipcclean in 8.1 broken?

Tom Lane <tgl@sss.pgh.pa.us> — 2006-03-03T17:21:31Z

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

Re: ipcclean in 8.1 broken?

Bruce Momjian <pgman@candle.pha.pa.us> — 2006-03-03T17:24:26Z

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. +

Re: ipcclean in 8.1 broken?

Tom Lane <tgl@sss.pgh.pa.us> — 2006-03-03T17:49:29Z

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

Re: ipcclean in 8.1 broken?

Bruce Momjian <pgman@candle.pha.pa.us> — 2006-03-03T18:00:59Z

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. +

Re: ipcclean in 8.1 broken?

Tom Lane <tgl@sss.pgh.pa.us> — 2006-03-03T18:27:56Z

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

Re: ipcclean in 8.1 broken?

Bruce Momjian <pgman@candle.pha.pa.us> — 2006-03-03T18:39:55Z

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. +

Re: ipcclean in 8.1 broken?

Michael Fuhr <mike@fuhr.org> — 2006-03-03T18:45:21Z

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

Re: ipcclean in 8.1 broken?

Michael Paesold <mpaesold@gmx.at> — 2006-03-03T18:49:08Z

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

Re: ipcclean in 8.1 broken?

Tom Lane <tgl@sss.pgh.pa.us> — 2006-03-03T18:49:23Z

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

Re: ipcclean in 8.1 broken?

Bruce Momjian <pgman@candle.pha.pa.us> — 2006-03-03T19:30:45Z

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. +

Re: ipcclean in 8.1 broken?

Andrew Dunstan <andrew@dunslane.net> — 2006-03-03T19:47:42Z

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