From: 1jam on
openSUSE 11.2 x86_64

On a stock 11.2 system, codeblocks will build and install fine (using latest
svn, or older).

But after some update is installed, root permissions get messed up. 'make
install' causes all directories that the install process creates to get
rwx------ permissions. This is wrong. Only root can run codeblocks like
this.

It should be rwxr-xr-x permissions on folders. (and it was before the
update).

I'm just not sure which update caused this change. I know it wasn't the sudo
or aaa_base updates because I haven't installed those yet. Looking thru
what is on the 11.2 update repo... maybe the libtool update?

If I can figure it out I'll file a bug report.
From: David Bolt on
On Tuesday 11 May 2010 06:34, while playing with a tin of spray paint,
1jam painted this mural:

> openSUSE 11.2 x86_64
>
> On a stock 11.2 system, codeblocks will build and install fine (using latest
> svn, or older).

There's a built package for revision 6216 available through the build
service, which is only a couple of revisions behind the latest svn
revision.

> But after some update is installed, root permissions get messed up. 'make
> install' causes all directories that the install process creates to get
> rwx------ permissions. This is wrong. Only root can run codeblocks like
> this.

Where did you install it? As it's locally built, it should be installed
somewhere under /usr/local , which is also the default location unless
you tell it otherwise, and so shouldn't end up having the directory
permissions changed.

> It should be rwxr-xr-x permissions on folders. (and it was before the
> update).

Well, if you expect it to work, yes they should be.

> I'm just not sure which update caused this change.

Do you know when the change took place?

> I know it wasn't the sudo
> or aaa_base updates because I haven't installed those yet. Looking thru
> what is on the 11.2 update repo... maybe the libtool update?

I don't think so. The package contents doesn't seem to claim ownership
of any directories that it shouldn't own.


Regards,
David Bolt

--
Team Acorn: www.distributed.net OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s
openSUSE 11.0 32b | | | openSUSE 11.3M4 32b
| openSUSE 11.1 64b | openSUSE 11.2 64b |
TOS 4.02 | openSUSE 11.1 PPC | RISC OS 4.02 | RISC OS 3.11

From: 1jam on
David Bolt wrote:

> On Tuesday 11 May 2010 06:34, while playing with a tin of spray paint,
> 1jam painted this mural:
>
>> openSUSE 11.2 x86_64
>>
>> On a stock 11.2 system, codeblocks will build and install fine (using
>> latest svn, or older).
>
> There's a built package for revision 6216 available through the build
> service, which is only a couple of revisions behind the latest svn
> revision.
>

Yes I know. But I like to be able to build the latest nightly from svn. Or
at least I should be able to if I want, without these problems.

>> But after some update is installed, root permissions get messed up. 'make
>> install' causes all directories that the install process creates to get
>> rwx------ permissions. This is wrong. Only root can run codeblocks like
>> this.
>
> Where did you install it? As it's locally built, it should be installed
> somewhere under /usr/local , which is also the default location unless
> you tell it otherwise, and so shouldn't end up having the directory
> permissions changed.
>

I let it do the default which is /usr/local as you say. I also tried a
custom location under /opt. Same problem occured.

>> It should be rwxr-xr-x permissions on folders. (and it was before the
>> update).
>
> Well, if you expect it to work, yes they should be.
>
>> I'm just not sure which update caused this change.
>
> Do you know when the change took place?
>

It is after installing updates on a fresh 11.2 install that this occurs.
(beforehand there is no problem). So some update in the 11.2 update repo is
to blame.

Note that it doesn't mess with the preexisting root folder you use
(/usr/local/share or whatever), it is only on the folders that it *creates*
underneath that root that the bad permissions are set.
(/usr/local/share/codeblocks/...

I think I will have to rollback one update at a time, try make install, and
repeat, until I find the naughty update. Maybe I'll setup a virtual machine.

From: 1jam on
I figured it out. It was a umask problem. Bizarrely the default umask for a
new users homedir, which I had changed, is taking precidence for ALL users
including root as their current umask. I'm filing a bug report.