Обсуждение: mode of libs
Is this Ok ?
/home/postgres/lib > ls -l
total 711
-r--r--r-- 1 postgres users 605 26 ÆÅ× 07:57 global1.bki.source
-r--r--r-- 1 postgres users 0 26 ÆÅ× 07:57 global1.description
-r--r--r-- 1 postgres users 8994 26 ÆÅ× 07:57 libecpg.a
lrwxrwxrwx 1 postgres users 14 26 ÆÅ× 07:57 libecpg.so -> libecpg.so.1.0
^ ^
-r--r--r-- 1 postgres users 16743 26 ÆÅ× 07:57 libecpg.so.1.0
-rw-rw-r-- 1 postgres users 82184 26 ÆÅ× 07:57 libpgtcl.a
^
lrwxrwxrwx 1 postgres users 15 26 ÆÅ× 07:57 libpgtcl.so -> libpgtcl.so.1.0
^ ^
-rw-rw-r-- 1 postgres users 81925 26 ÆÅ× 07:57 libpgtcl.so.1.0
^
-rw-rw-r-- 1 postgres users 157494 26 ÆÅ× 07:57 libpq.a
^
lrwxrwxrwx 1 postgres users 12 26 ÆÅ× 07:57 libpq.so -> libpq.so.1.1
^ ^
-rw-rw-r-- 1 postgres users 152325 26 ÆÅ× 07:57 libpq.so.1.1
^
Vadim
> > Is this Ok ? > > /home/postgres/lib > ls -l > total 711 > -r--r--r-- 1 postgres users 605 26 ��� 07:57 global1.bki.source > -r--r--r-- 1 postgres users 0 26 ��� 07:57 global1.description > -r--r--r-- 1 postgres users 8994 26 ��� 07:57 libecpg.a > lrwxrwxrwx 1 postgres users 14 26 ��� 07:57 libecpg.so -> libecpg.so.1.0 > ^ ^ Good eye. Fixed. Was in configure.in as 664 not 644. No reason to give group write permission, right? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
Bruce Momjian wrote: > > > > > Is this Ok ? > > > > /home/postgres/lib > ls -l > > total 711 > > -r--r--r-- 1 postgres users 605 26 ÆÅ× 07:57 global1.bki.source > > -r--r--r-- 1 postgres users 0 26 ÆÅ× 07:57 global1.description > > -r--r--r-- 1 postgres users 8994 26 ÆÅ× 07:57 libecpg.a > > lrwxrwxrwx 1 postgres users 14 26 ÆÅ× 07:57 libecpg.so -> libecpg.so.1.0 > > ^ ^ > > Good eye. Fixed. Was in configure.in as 664 not 644. No reason to > give group write permission, right? Yes. And "others" too... Vadim
> > Bruce Momjian wrote: > > > > > > > > Is this Ok ? > > > > > > /home/postgres/lib > ls -l > > > total 711 > > > -r--r--r-- 1 postgres users 605 26 ��� 07:57 global1.bki.source > > > -r--r--r-- 1 postgres users 0 26 ��� 07:57 global1.description > > > -r--r--r-- 1 postgres users 8994 26 ��� 07:57 libecpg.a > > > lrwxrwxrwx 1 postgres users 14 26 ��� 07:57 libecpg.so -> libecpg.so.1.0 > > > ^ ^ > > > > Good eye. Fixed. Was in configure.in as 664 not 644. No reason to > > give group write permission, right? > > Yes. And "others" too... Now there is a bigger problem. pg_pwd is mode rw-rw-rw- because a COPY is used to create it. Any ideas how to fix this? Copy sets the permissions to this before it creates the file. It temporarily changes the umask to create the file. If pg_pwd ever has data in it and it is world-readable, it is unsecure. Anyone have a brilliant idea on a fix? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> Now there is a bigger problem. pg_pwd is mode rw-rw-rw- because a COPY
> is used to create it. Any ideas how to fix this? Copy sets the
> permissions to this before it creates the file. It temporarily changes
> the umask to create the file. If pg_pwd ever has data in it and it is
> world-readable, it is unsecure.
>
> Anyone have a brilliant idea on a fix?
Well, the data directory itself is protected from anyone other than the postgres
account, so it may not matter as much if an individual file is not right. My (former)
Ingres installation had the directory protected, and then permissions of 777 on all the
directories and files within it as I recall...
We should fix it up to match the protections on other files though...
- Tom
> Well, the data directory itself is protected from anyone other than the postgres > account, so it may not matter as much if an individual file is not right. My (former) > Ingres installation had the directory protected, and then permissions of 777 on all the > directories and files within it as I recall... > > We should fix it up to match the protections on other files though... Not true. As long as someone has read or execute permission on a directory, they can read/write any file in that directory they have permission for. What they can't do is add or delete file based on the directory permission. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> > Well, the data directory itself is protected from anyone other than the postgres
> > account, so it may not matter as much if an individual file is not right. My (former)
> > Ingres installation had the directory protected, and then permissions of 777 on all the
> > directories and files within it as I recall...
> >
> > We should fix it up to match the protections on other files though...
>
> Not true. As long as someone has read or execute permission on a
> directory, they can read/write any file in that directory they have
> permission for. What they can't do is add or delete file based on the
> directory permission.
Sure. I must be missing the point (as usual :), because my directory protections look like:
golem> dir
...
142 drwx------ 3 postgres postgres 1024 Feb 24 03:38 data/
...
golem> dir data
ls: data: Permission denied
golem> dir data/pg_pwd
ls: data/pg_pwd: Permission denied
golem> cat data/pg_pwd
cat: data/pg_pwd: Permission denied
??
- Tom
> > Not true. As long as someone has read or execute permission on a > > directory, they can read/write any file in that directory they have > > permission for. What they can't do is add or delete file based on the > > directory permission. > > Sure. I must be missing the point (as usual :), because my directory protections look like: Sorry, count me an idiot. I see what you mean now. The pgsql/data directory is rw-------, which makes all files underneath unreadable by anyone but the superuser. There is no problem. Sorry. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
On Wed, 25 Feb 1998, Bruce Momjian wrote:
> Now there is a bigger problem. pg_pwd is mode rw-rw-rw- because a COPY
> is used to create it. Any ideas how to fix this? Copy sets the
> permissions to this before it creates the file. It temporarily changes
> the umask to create the file. If pg_pwd ever has data in it and it is
> world-readable, it is unsecure.
>
> Anyone have a brilliant idea on a fix?
Why, again, is COPY creating files 666? 600, IMHO, sounds more
appropriate, but I imagine there has to be a reason why it is 666...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > On Wed, 25 Feb 1998, Bruce Momjian wrote: > > > Now there is a bigger problem. pg_pwd is mode rw-rw-rw- because a COPY > > is used to create it. Any ideas how to fix this? Copy sets the > > permissions to this before it creates the file. It temporarily changes > > the umask to create the file. If pg_pwd ever has data in it and it is > > world-readable, it is unsecure. > > > > Anyone have a brilliant idea on a fix? > > Why, again, is COPY creating files 666? 600, IMHO, sounds more > appropriate, but I imagine there has to be a reason why it is 666... Because the owner is postgres, not the user running the psql copy command. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)