Bug 81905 - incorrect permissions on /etc/init.d/postgresql
Summary: incorrect permissions on /etc/init.d/postgresql
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: postgresql (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Andrew Overholt
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-15 02:18 UTC by Chris Ricker
Modified: 2007-04-18 16:49 UTC (History)
0 users

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


Attachments (Terms of Use)

Description Chris Ricker 2003-01-15 02:18:47 UTC
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 16:10:21 UTC
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 16:15:30 UTC
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.