Executable files in CVS

While people add more executable files to CVS (cf. initdb.c), can we do
something about it?

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut wrote:
> While people add more executable files to CVS (cf. initdb.c), can we do
> something about it?

Sure. I logged into the main server machine and cd'ed to CVSROOT. I
then when to the src/bin/initdb directory, and because I didn't have
permisssions, I moved initdb.c,v to another file name then copied it to
the original name so I owned the file. I then removed the execute bits
from the file. I did that for initdb.c and dirmod.c. I then removed
files from my local CVS and did a CVS update and the files no longer
have execute bits.

I looked at my CVS and didn't see any more problem files. Do you see
any others?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Sure. I logged into the main server machine and cd'ed to CVSROOT. I
> then when to the src/bin/initdb directory, and because I didn't have
> permisssions, I moved initdb.c,v to another file name then copied it to
> the original name so I owned the file. I then removed the execute bits
> from the file. I did that for initdb.c and dirmod.c. I then removed
> files from my local CVS and did a CVS update and the files no longer
> have execute bits.

Um. Can anyone else check into those files now?

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Sure. I logged into the main server machine and cd'ed to CVSROOT. I
> > then when to the src/bin/initdb directory, and because I didn't have
> > permisssions, I moved initdb.c,v to another file name then copied it to
> > the original name so I owned the file. I then removed the execute bits
> > from the file. I did that for initdb.c and dirmod.c. I then removed
> > files from my local CVS and did a CVS update and the files no longer
> > have execute bits.
>
> Um. Can anyone else check into those files now?

Yes, I think so. The file used to be owned by Peter, but now by me:

-r--rw-r-- 1 petere pgsql 19139 Nov 23 17:42 Makefile,v
-r--r--r-- 1 momjian pgsql 86195 Nov 23 19:00 initdb.c,v
-r--r--r-- 1 petere pgsql 299 Nov 23 17:41 nls.mk,v

initdb.c looks pretty much the same as the other files in the directory.
They look pretty much the directory. Are you seeing a problem?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Sun, Nov 23, 2003 at 06:59:45PM -0500, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Sure. I logged into the main server machine and cd'ed to CVSROOT. I
> > then when to the src/bin/initdb directory, and because I didn't have
> > permisssions, I moved initdb.c,v to another file name then copied it to
> > the original name so I owned the file. I then removed the execute bits
> > from the file. I did that for initdb.c and dirmod.c. I then removed
> > files from my local CVS and did a CVS update and the files no longer
> > have execute bits.
>
> Um. Can anyone else check into those files now?

Looks fine in CVSup. But in src/port I now see a file named "x" that
appears to be the old dirmod.c,v ...

BTW, I can see a whole lot of files with the executable bit:

find pgsql-server/ -type f -perm +0333 -ls

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Those who use electric razors are infidels destined to burn in hell while
we drink from rivers of beer, download free vids and mingle with naked
well shaved babes." (http://slashdot.org/comments.pl?sid=44793&cid=4647152)

Alvaro Herrera wrote:
> On Sun, Nov 23, 2003 at 06:59:45PM -0500, Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > Sure. I logged into the main server machine and cd'ed to CVSROOT. I
> > > then when to the src/bin/initdb directory, and because I didn't have
> > > permisssions, I moved initdb.c,v to another file name then copied it to
> > > the original name so I owned the file. I then removed the execute bits
> > > from the file. I did that for initdb.c and dirmod.c. I then removed
> > > files from my local CVS and did a CVS update and the files no longer
> > > have execute bits.
> >
> > Um. Can anyone else check into those files now?
>
> Looks fine in CVSup. But in src/port I now see a file named "x" that
> appears to be the old dirmod.c,v ...

Thanks, removed.

> BTW, I can see a whole lot of files with the executable bit:
>
> find pgsql-server/ -type f -perm +0333 -ls

That command doesn't seem to work for me. I see:

8 -r--rw-r-- 1 pgsql pgsql 2405 Nov 16 17:34 ./contrib/btree_gist/btree_common.c,v

which doesn't have execute permission.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> Um. Can anyone else check into those files now?

> Yes, I think so. The file used to be owned by Peter, but now by me:

Oh, okay. I had the idea they should all be owned by the cvs daemon,
but I guess that's not required.

> -r--rw-r-- 1 petere pgsql 19139 Nov 23 17:42 Makefile,v
> -r--r--r-- 1 momjian pgsql 86195 Nov 23 19:00 initdb.c,v
> -r--r--r-- 1 petere pgsql 299 Nov 23 17:41 nls.mk,v

Hmmm ... why is the Makefile group-writable?

I did this to look for other permissions issues:

find . -type f -a -perm +313 | grep -v /Attic/ | xargs ls -l

The following files look dubious to me:

contrib/README
contrib/lo/Makefile
doc/FAQ_hungarian
src/backend/catalog/system_views.sql
src/backend/port/tas/solaris_i386.s
src/backend/port/tas/solaris_sparc.s
src/interfaces/jdbc/example/corba/stock.idl
src/pl/tcl/modules/pltcl_delmod.in
src/pl/tcl/modules/pltcl_listmod.in
src/pl/tcl/modules/pltcl_loadmod.in
src/test/locale/koi8-r/test-koi8.sql.in

The other things that are executable look like they legitimately are
scripts.

If we consider that group-writability is bad (which ISTM we ought to)
then there are a *ton* of files with the wrong permissions. I'd
recommend getting Marc to fix it instead of hacking about with a
one-file-at-a-time method.

regards, tom lane

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Alvaro Herrera wrote:
>> BTW, I can see a whole lot of files with the executable bit:
>>
>> find pgsql-server/ -type f -perm +0333 -ls

> That command doesn't seem to work for me.

He's looking for *either* write or execute permissions. AFAIK there is
no reason for any ordinary file in a CVS repository to have write
permissions.

regards, tom lane

On Mon, 24 Nov 2003 11:41 am, Bruce Momjian wrote:
> > find pgsql-server/ -type f -perm +0333 -ls
>
> That command doesn't seem to work for me. I see:

I think that should be -perm +0111:

from man find:
-perm +mode
Any of the permission bits mode are set for the file.

This would find all executable files (by u,g,o). +0333 would also find
writable files (as in your example)

Regards, Philip.

> The other things that are executable look like they legitimately are
> scripts.
>
> If we consider that group-writability is bad (which ISTM we ought to)
> then there are a *ton* of files with the wrong permissions. I'd
> recommend getting Marc to fix it instead of hacking about with a
> one-file-at-a-time method.

You could consider adding a script to CVSROOT module to fix permissions
upon commit?

Chris

Christopher Kings-Lynne wrote:
> > The other things that are executable look like they legitimately are
> > scripts.
> >
> > If we consider that group-writability is bad (which ISTM we ought to)
> > then there are a *ton* of files with the wrong permissions. I'd
> > recommend getting Marc to fix it instead of hacking about with a
> > one-file-at-a-time method.
>
> You could consider adding a script to CVSROOT module to fix permissions
> upon commit?

Some files need execute bits, like perl scripts.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Christopher Kings-Lynne wrote:
>> You could consider adding a script to CVSROOT module to fix permissions
>> upon commit?

> Some files need execute bits, like perl scripts.

Sure, but couldn't we automatically turn off the write bits?

regards, tom lane

On Sun, 23 Nov 2003, Tom Lane wrote:

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Christopher Kings-Lynne wrote:
> >> You could consider adding a script to CVSROOT module to fix permissions
> >> upon commit?
>
> > Some files need execute bits, like perl scripts.
>
> Sure, but couldn't we automatically turn off the write bits?

Just curious, but what do the write bits harm? Everyone that has access
to that VM has acccess to CVSROOT, either through CVS or directly ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> On Sun, 23 Nov 2003, Tom Lane wrote:
>> Sure, but couldn't we automatically turn off the write bits?

> Just curious, but what do the write bits harm?

They're just extra protection against making a dumb mistake; the old
belt-AND-suspenders theory.

If we were to turn off group write permission on the CVS directories,
then the protection would be a lot stronger, but it would also prevent
manual fixes of the sort Bruce just made (or manual removal of stale
CVS lock files, as I can recall having to do several times). So I'm not
in favor of that. But "no write on the CVS data files" seems like a
good compromise policy.

Besides, it's a tad odd to see files that are marked group writable but
not owner writable. You've got to agree there's not much sense in that.

regards, tom lane

Tom Lane writes:

> Besides, it's a tad odd to see files that are marked group writable but
> not owner writable. You've got to agree there's not much sense in that.

How else are you going to commit files? /usr/bin/cvs is not setuid, so
the only way you can write to these files is being in the group pgsql and
that group having write permission.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> Besides, it's a tad odd to see files that are marked group writable but
>> not owner writable. You've got to agree there's not much sense in that.

> How else are you going to commit files? /usr/bin/cvs is not setuid,

Sure, but as long as the directories are group-writable it can rename
the old version out of the way. Which is what I think it's actually
doing, because there are some files in the tree that are not group
writable --- src/backend/commands/alter.c,v is an example.

regards, tom lane