Bug 81905 - incorrect permissions on /etc/init.d/postgresql
incorrect permissions on /etc/init.d/postgresql
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: postgresql (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Andrew Overholt
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-14 21:18 EST by Chris Ricker
Modified: 2007-04-18 12:49 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-15 11:15:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Ricker 2003-01-14 21:18:47 EST
On a fully up2date'd RHL 8 machine, the new postgresql-server-7.2.3-5.80 RPM
installs an /etc/init.d/postgresql with incorrect permissions. It's now not
world-readable like all the other init scripts.

[kaboom@verdande lib]$ ls -l /etc/init.d/postgresql 
-rwx------    1 root     root         6157 Dec 20 10:57 /etc/init.d/postgresql
[kaboom@verdande lib]$ 

If I remember right, this bug is introduced by the errata -- I think it was
correctly 755 before the update
Comment 1 Andrew Overholt 2003-01-15 11:10:21 EST
This was an oversight on my part and I apologize.  However, we have discussed
the issue and have decided not to reissue the erratum with a modified
initscript.  Hopefully this will not cause any real problems.

Should a non-root user wish to run the initscript for status purposes, they can
get the same output by executing the following commands:

$ /sbin/pidof postmaster
(this will give you the process ID's of any running postmasters)

$ cat /var/run/postmaster.pid
(if the first command output nothing, but this command indicates that the file
exists, then the service is most likely not running but crashed somehow so an
old process ID is stored there to prevent it from restarting and potentially
harming data)

$ cat /var/lock/subsys/postgresql
(if the above two commands output nothing, but this command indicates that the
lockfile exists, then something happened to cause the postgresql system to lock.
 Data integrity should be verified and backups made prior to attempting to
delete this file and/or restart the postmaster in this case)

If none of these commands indicated the situations described above, then the
database system is not currently running and it *should* be safe to start it
back up (obviously as root if you're using the initscript).

HTH.
Comment 2 David Lawrence 2003-01-15 11:15:30 EST
Changing resolution to RAWHIDE since this is will be fixed in future releases of
PostgreSQL.

Note You need to log in before you can comment on or make changes to this bug.