Обсуждение: ipcclean in 8.1 broken?
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
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
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
Simulatea full login. The environment is discarded except for HOME, SHELL, PATH, TERM, and USER. HOME and
SHELLare modified as above. USER is set to the target login. PATH is set to ``/bin:/usr/bin''.
TERMis 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 > 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
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 ] [ -ddebug-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. + Index: src/bin/ipcclean/ipcclean.sh =================================================================== RCS file: /cvsroot/pgsql/src/bin/ipcclean/ipcclean.sh,v retrieving revision 1.16 diff -c -c -r1.16 ipcclean.sh *** src/bin/ipcclean/ipcclean.sh 5 Jan 2006 01:56:29 -0000 1.16 --- src/bin/ipcclean/ipcclean.sh 3 Mar 2006 16:48:43 -0000 *************** *** 19,25 **** exit 0 fi ! if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ] then ( echo "$CMDNAME: cannot be run as root" 1>&2 --- 19,26 ---- exit 0 fi ! # only check $LOGNAME if $USER is not set ! if [ "$USER" = 'root' -o \( ! "$USER" -a "$LOGNAME" = 'root' \) ] then ( echo "$CMDNAME: cannot be run as root" 1>&2
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 appropriateprivileges. 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 maybe understood as a synonym for "superuser" (UID 0). However, other systems have emerged where this is not the case andeach 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