User forums > Help

C::B directory permissions under Linux

(1/3) > >>

stardust:
Hi all,

I just generated Code::Blocks from source and installed it under SuSE 10.0.x.

The build (bootstrap, configure, make) run as ordinary user and the installation (make install) as root. However, the installation is unusable due to bad permissions:


--- Code: ---> ll /usr/local/share/
insgesamt 32
drwxrwxr-x  2 root root 4096 2007-01-08 14:58 aclocal
drwxrwx---  2 root root 4096 2007-01-09 11:20 application-registry
drwxrwx---  2 root root 4096 2007-01-09 11:20 applications
drwxrwx---  8 root root 4096 2007-01-09 11:20 codeblocks
drwxrwx---  3 root root 4096 2007-01-09 11:20 icons
drwxrwx---  3 root root 4096 2007-01-09 11:20 mime
drwxrwx---  2 root root 4096 2007-01-09 11:20 mime-info
drwxrwx---  2 root root 4096 2007-01-09 11:20 pixmaps

--- End code ---

As you can see, ordinary users will get a permission denied when trying to start C::B resp. when trying to read needed files. Same applies to /usr/local/include/codeblocks when trying to read.

The reason is found in /etc/profile


--- Code: ---# The user file-creation mask
#
#umask 022
umask 0007

--- End code ---

According to my admin this is necessary in order not to violate LDAP security.

The C::B install process sets permissions for files to 644, but does not adapt the rights for the topmost directories to 755 like in


--- Code: ---test -z "/usr/local/share/codeblocks" || mkdir -p -- "/usr/local/share/codeblocks" ...
--- End code ---

Must I change all these permissions by hand? Or is this a defiecency of the C::B install script and a bug?

Greets

mandrav:
The installation process is handled by autotools. I 'm not sure there's anything we can do about it...

stardust:
Thanks.

In aclocal.m4 I found the following:


--- Code: ---# AM_PROG_MKDIR_P
# ---------------
# Check whether `mkdir -p' is supported, fallback to mkinstalldirs otherwise.
#
# Automake 1.8 used `mkdir -m 0755 -p --' to ensure that directories
# created by `make install' are always world readable, even if the
# installer happens to have an overly restrictive umask (e.g. 077).
# This was a mistake.  There are at least two reasons why we must not
# use `-m 0755':
#   - it causes special bits like SGID to be ignored,
#   - it may be too restrictive (some setups expect 775 directories).
#
# Do not use -m 0755 and let people choose whatever they expect by
# setting umask.

--- End code ---

so I will have to bother my admin again... :?

However, the message that C::B brings up upon startup is misleading.

--- Code: ---Cannot find resources...
Code::Blocks was configured to be installed in '/usr/local/share/codeblocks'.
Please use the command-line switch '--prefix' or set the CODEBLOCKS_DATA_DIR environment variable to point where Code::Blocks is installed,
or try re-installing the application...
--- End code ---

It is perhaps a good idea to check for the permissions in C::B and give a hint that is closer to the very problem (changing permissions resp. umask).

stardust:
Hi again,

in order to avoid all the trouble, I am trying to install Code::Blocks into a sandbox where I have all permissions.

configure ran with
--- Code: -----prefix=/local/codeblocks
--- End code ---
with /local a soft link to my sandbox.

make install runs until it aborts with

--- Code: ---test -z "/local/codeblocks/share/codeblocks/plugins" || mkdir -p -- "/local/codeblocks/share/codeblocks/plugins"
 /bin/sh ../../../libtool --mode=install /usr/bin/install -c  'libastyle.la' '/local/codeblocks/share/codeblocks/plugins/libastyle.la'
libtool: install: error: cannot install `libastyle.la' to a directory not ending in /usr/local/share/codeblocks/plugins
make[5]: *** [install-libLTLIBRARIES] Fehler 1

--- End code ---

umask is the same as above (0007). However, As I am the owner of all the stuff it should work.

I did browse ./configure but no option addresses that. I would rather expect specifying a lib by adapting some path variable instead of a hard coded install path/path to find it.

So I am stuck again. Do you have a clue?


Thanks.

mandrav:
You have built originally with a different 'prefix=' argument for 'configure'.
To solve this, run "make clean-bin && make" and then "make install" should work.

Navigation

[0] Message Index

[#] Next page