LinuxQuestions.org - [SOLVED] Some application installation questions: log in as root or log in as 'user' & do 'su'

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Some application installation questions: log in as root or log in as 'user' & do 'su' (https://www.linuxquestions.org/questions/slackware-14/some-application-installation-questions-log-in-as-root-or-log-in-as-user-and-do-su-864764/)

Some application installation questions: log in as root or log in as 'user' & do 'su'

Hello:

If you have the time, and the patience, I am trying to understand the differences and/or implications of 'logging in as root to down load & install applications' vs 'logging as 'rob' (a user) to down load & install applications', if any.

And, are there any further considerations based on whether you are down loading a SlackBuild vs a tarred applications from some other reputable web site on the net?

Are there any nuances to be aware of?

I am trying to understand if there are differences to the 'result of the install'.

Thanks,

There is no difference, just when you installing apps you need to have root privileges to copy files to system directories. The only difference will be the owner of downloaded file, which if it is dll'd as root, user rob won't be able to modify or delete it. AFAIK best solution is to download, untar, "./configure" and "make" as user and "make install" as root.

If you're downloading and building an application; i.e., executing a "packagename.SlackBuild," you will probably be able to do so -- "probably" means that you may have access to all the libraries and any utilities required to successfully build a package. You will not, however, be able to install it logged in a "you;" you must have root permissions to install (using su, sudo or logged in as root.

The same is true of a tar bundle you get from somewhere or other; you'll probably be able to execute configure and make but not make install unless you've root permissions.

The above both assume that you're downloading into your home directory (or /tmp) and compiling there. I would be better if you have a /usr/local/src type of directory tree for stuff you add on to the system -- you'll always know where stuff is and you won't be wading through a forest in your home directory (of course you could have a src tree in your home directory instead -- up to you). Generally speaking, if you have a /usr/local/src tree, it'll be owned by root and you as a user will not be able to write in the tree. So, you'd need to use su or sudo to build and install stuff there. Six of one, half dozen of the other.

Working logged in as root is not for the faint of heart. Inevitably, you'll screw up and blow a lot of stuff away that you did not mean to do. So, not such a good idea.

Working with su or sudo is probably the best way to go -- you don't have to fiddle with granting permissions on directories that ought to be left alone and the chances of wiping out the system are significantly less. On thing you may want to do is edit /etc/login.defs to change the behavior of su. Used to be the default of su - was "as if logged in as;" i.e., you would get the profile of the user you "su-ed" as. Nowadays, the default behavior is that you do not get the profile unless you edit /etc/login.defs to comment-out the line

Code:

#

# If defined, the command name to display when running "su -".  For

# example, if this is defined as "su" then a "ps" will display the

# command is "-su".  If not defined, then "ps" would display the

# name of the shell actually being run, e.g. something like "-sh".

#

SU_NAME                su                        <comment-out this line (put a # in column 1)>

When you do the above and execute su - fred you will be "fred" as if you logged in on the console. If you su - you will be root as if you logged in as root on the console.

Are then any considerations about a tarball downloaded from, oh, say, SourceForge.net versus SlackBuilds.org? Well, no, probably not (but the SlackBuild will be easier to do 'cause you don't have to think about configuration options and the like).

Learn to use src2pkg if you're building stuff from non-SlackBuilds.org sites. It's a good tool. RTFM.

Hope this helps some.

The other advantage to building from source via slackbuilds as opposed to installing a pre-built package from another system is that the software will usually be optimized for YOUR system rather than for someone elses, this can make a difference in the speed and stability of the app, both ways have their advantages, I have a couple of progs installed from converted RPM,s simply because of convenience or the fact that they would not build on my system, but I usually try to install either from slackbuilds or via svn/cvs/git etc and then build a package myself.

Gotta love so many options in slackware!

Quote:

Originally Posted by tronayne (Post 4269756)

Working with su or sudo is probably the best way to go -- you don't have to fiddle with granting permissions on directories that ought to be left alone and the chances of wiping out the system are significantly less. On thing you may want to do is edit /etc/login.defs to change the behavior of su. Used to be the default of su - was "as if logged in as;" i.e., you would get the profile of the user you "su-ed" as. Nowadays, the default behavior is that you do not get the profile unless you edit /etc/login.defs to comment-out the line

Code:

#

# If defined, the command name to display when running "su -".  For

# example, if this is defined as "su" then a "ps" will display the

# command is "-su".  If not defined, then "ps" would display the

# name of the shell actually being run, e.g. something like "-sh".

#

SU_NAME                su                        <comment-out this line (put a # in column 1)>

When you do the above and execute su - fred you will be "fred" as if you logged in on the console. If you su - you will be root as if you logged in as root on the console.

This part appears to be simply wrong.

In my Slackware64 13.1 system, the above line in /etc/login.defs is not commented out and the command...

Code:

su -

..."provides an environment similar to what the user would expect had the user logged in directly."

Quote:

Originally Posted by Richard Cranium (Post 4270112)

This part appears to be simply wrong.

In my Slackware64 13.1 system, the above line in /etc/login.defs is not commented out and the command...

Code:

su -

..."provides an environment similar to what the user would expect had the user logged in directly."

Same here. This should be normal behaviour as far as I know.

Well, kinda. If that line is not commented out and you're logged in as you and you execute su -, yeah, you get to be godlike but you do not get root's environment (or, for that matter, if you su - someuser, you will not get that user's profile). At least in Korn Shell (which I use) although I do not believe that has anything to do with it; but maybe...

If it is commented out (the way I prefer it) and you su - you get root's profile (or some other user).

Sorry, but I come from SVR4 and Solaris and that's the way they work (thus the way I prefer) and at some point a few years back Slackware stopped working that way and I had to remember to comment out that particular line to get things to behave way I prefer. I have users that have different profiles and when I need to be that user I need to have that profile for testing and making sure that things work as they should for that user and applications used by that user.

Not a big deal, just different than it used to be (in Slackware, about 10.x I think maybe).

No tempest, no teapot and all is well that ends.

A true console login session vs. `su -` (running `env` in each one and storing to a file):

Code:

# diff -u envlogin.txt envsu-.txt

--- envlogin.txt        2011-02-24 18:39:58.182773617 -0500

+++ envsu-.txt  2011-02-24 18:40:13.710903314 -0500

@@ -3,10 +3,9 @@

 HZ=100

 HOSTNAME=LinuxPC.localdomain

 SHELL=/bin/bash

-TERM=linux

-HUSHLOGIN=FALSE

+TERM=screen-256color-bce

 USER=root

-LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.bat=01;32:*.BAT=01;32:*.btm=01;32:*.BTM=01;32:*.cmd=01;32:*.CMD=01;32:*.com=01;32:*.COM=01;32:*.dll=01;32:*.DLL=01;32:*.exe=01;32:*.EXE=01;32:*.7z=01;31:*.ace=01;31:*.arj=01;31:*.bz2=01;31:*.cpio=01;31:*.deb=01;31:*.dz=01;31:*.gz=01;31:*.jar=01;31:*.lzh=01;31:*.lzma=01;31:*.rar=01;31:*.RAR=01;31:*.rpm=01;31:*.rz=01;31:*.tar=01;31:*.taz=01;31:*.tb2=01;31:*.tbz2=01;31:*.tbz=01;31:*.tgz=01;31:*.tlz=01;31:*.trz=01;31:*.txz=01;31:*.tz=01;31:*.tz2=01;31:*.xz=01;31:*.z=01;31:*.Z=01;31:*.zip=01;31:*.ZIP=01;31:*.zoo=01;31:*.aac=00;35:*.anx=01;35:*.asf=01;35:*.ASF=01;35:*.au=00;35:*.axa=00;35:*.axv=01;35:*.avi=01;35:*.AVI=01;35:*.bmp=01;35:*.BMP=01;35:*.flac=01;35:*.FLAC=01;35:*.gif=01;35:*.GIF=01;35:*.jpg=01;35:*.JPG=01;35:*.jpeg=01;35:*.JPEG=01;35:*.m2a=01;35:*.M2A=01;35:*.m2v=01;35:*.M2V=01;35:*.m4a=01;35:*.M4A=01;35:*.m4p=01;35:*.M4P=01;35:*.m4v=01;35:*.M4V=01;35:*.mid=00;35:*.midi=00;35:*.mka=00;35:*.mov=01;35:*.MOV=01;35:*.mp3=01;35:*.MP3=01;35:*.mp4=01;35:*.mp4v=01;35:*.mpc=01;35:*.MPC=01;35:*.mpeg=01;35:*.MPEG=01;35:*.mpg=01;35:*.MPG=01;35:*.nuv=01;35:*.oga=00;35:*.ogv=01;35:*.ogx=01;35:*.ogg=01;35:*.OGG=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.PNG=01;35:*.ppm=01;35:*.qt=01;35:*.ra=00;35:*.ram=01;35:*.RAM=01;35:*.rm=01;35:*.RM=01;35:*.spx=00;35:*.svg=01;35:*.svgz=01;35:*.tga=01;35:*.TGA=01;35:*.tif=01;35:*.TIF=01;35:*.tiff=01;35:*.TIFF=01;35:*.vob=01;35:*.wav=01;35:*.WAV=01;35:*.wma=01;35:*.WMA=01;35:*.wmv=01;35:*.WMV=01;35:*.xbm=01;35:*.xcf=01;35:*.xpm=01;35:*.xspf=00;35:*.xwd=01;35:*.XWD=01;35:

+LS_COLORS=

 GDK_USE_XFT=1

 T1LIB_CONFIG=/usr/share/t1lib/t1lib.config

 XDG_CONFIG_DIRS=/etc/xdg:/etc/kde/xdg:/etc/xfce/xdg

@@ -29,5 +28,8 @@

 LOGNAME=root

 PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/lib64/pkgconfig

 LESSOPEN=|lesspipe.sh %s

+DISPLAY=:0.0

 G_BROKEN_FILENAMES=1

+XAUTHORITY=/home/username/.Xauthority

+COLORTERM=rxvt-xpm

 _=/usr/bin/env

The TERM is obviously fine since I ran `su -` from urxvt in X, HUSHLOGIN is false in a login session but not in a `su` session (as expected), LS_COLORS is different because my urxvt has no proper entry in /etc/DIR_COLORS, DISPLAY is set because I'm in X, XAUTHORITY is set again because I'm in X (as another user), and COLORTERM again has to do with my terminal. The only significant difference is HUSHLOGIN which is set as expected. This is without modification to /etc/login.defs (on 64-bit 13.1).

The same true login session vs. `su` (no dash):

Code:

# diff -u envlogin.txt envsu.txt

--- envlogin.txt        2011-02-24 18:39:58.182773617 -0500

+++ envsu.txt  2011-02-24 18:40:49.679778285 -0500

@@ -3,31 +3,61 @@

 HZ=100

 HOSTNAME=LinuxPC.localdomain

 SHELL=/bin/bash

-TERM=linux

+TERM=screen-256color-bce

+XDG_SESSION_COOKIE=(random key here)

+WINDOWID=20971526

 HUSHLOGIN=FALSE

 USER=root

 LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.bat=01;32:*.BAT=01;32:*.btm=01;32:*.BTM=01;32:*.cmd=01;32:*.CMD=01;32:*.com=01;32:*.COM=01;32:*.dll=01;32:*.DLL=01;32:*.exe=01;32:*.EXE=01;32:*.7z=01;31:*.ace=01;31:*.arj=01;31:*.bz2=01;31:*.cpio=01;31:*.deb=01;31:*.dz=01;31:*.gz=01;31:*.jar=01;31:*.lzh=01;31:*.lzma=01;31:*.rar=01;31:*.RAR=01;31:*.rpm=01;31:*.rz=01;31:*.tar=01;31:*.taz=01;31:*.tb2=01;31:*.tbz2=01;31:*.tbz=01;31:*.tgz=01;31:*.tlz=01;31:*.trz=01;31:*.txz=01;31:*.tz=01;31:*.tz2=01;31:*.xz=01;31:*.z=01;31:*.Z=01;31:*.zip=01;31:*.ZIP=01;31:*.zoo=01;31:*.aac=00;35:*.anx=01;35:*.asf=01;35:*.ASF=01;35:*.au=00;35:*.axa=00;35:*.axv=01;35:*.avi=01;35:*.AVI=01;35:*.bmp=01;35:*.BMP=01;35:*.flac=01;35:*.FLAC=01;35:*.gif=01;35:*.GIF=01;35:*.jpg=01;35:*.JPG=01;35:*.jpeg=01;35:*.JPEG=01;35:*.m2a=01;35:*.M2A=01;35:*.m2v=01;35:*.M2V=01;35:*.m4a=01;35:*.M4A=01;35:*.m4p=01;35:*.M4P=01;35:*.m4v=01;35:*.M4V=01;35:*.mid=00;35:*.midi=00;35:*.mka=00;35:*.mov=01;35:*.MOV=01;35:*.mp3=01;35:*.MP3=01;35:*.mp4=01;35:*.mp4v=01;35:*.mpc=01;35:*.MPC=01;35:*.mpeg=01;35:*.MPEG=01;35:*.mpg=01;35:*.MPG=01;35:*.nuv=01;35:*.oga=00;35:*.ogv=01;35:*.ogx=01;35:*.ogg=01;35:*.OGG=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.PNG=01;35:*.ppm=01;35:*.qt=01;35:*.ra=00;35:*.ram=01;35:*.RAM=01;35:*.rm=01;35:*.RM=01;35:*.spx=00;35:*.svg=01;35:*.svgz=01;35:*.tga=01;35:*.TGA=01;35:*.tif=01;35:*.TIF=01;35:*.tiff=01;35:*.TIFF=01;35:*.vob=01;35:*.wav=01;35:*.WAV=01;35:*.wma=01;35:*.WMA=01;35:*.wmv=01;35:*.WMV=01;35:*.xbm=01;35:*.xcf=01;35:*.xpm=01;35:*.xspf=00;35:*.xwd=01;35:*.XWD=01;35:

 GDK_USE_XFT=1

+TERMCAP=SC|screen-256color-bce|VT 100/ANSI X3.64 virtual terminal:\

+      :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\

+      :cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\

+      :do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\

+      :le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\

+      :li#22:co#185:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\

+      :cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\

+      :im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\

+      :ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\

+      :ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E[24m:so=\E[3m:\

+      :se=\E[23m:mb=\E[5m:md=\E[1m:mr=\E[7m:me=\E[m:ms:\

+      :Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\

+      :vb=\Eg:G0:as=\E(0:ae=\E(B:\

+      :ac=\140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\

+      :po=\E[5i:pf=\E[4i:k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:\

+      :k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:\

+      :k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:F3=\E[25~:\

+      :F4=\E[26~:F5=\E[28~:F6=\E[29~:F7=\E[31~:F8=\E[32~:\

+      :F9=\E[33~:FA=\E[34~:kb=:K1=\EOw:K2=\EOu:K3=\EOy:\

+      :K4=\EOq:K5=\EOs:kB=\E[Z:kE=\E[8\^:*4=\E[3$:*7=\E[8$:\

+      :#2=\E[7$:#3=\E2$:#4=\E[d:%c=\E[6$:%e=\E[5$:%i=\E[c:\

+      :kh=\E[1~:@1=\E[1~:kH=\E[4~:@7=\E[4~:kN=\E[6~:kP=\E[5~:\

+      :kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:km:

+PAGER=/home/username/.bin/vimpager

 T1LIB_CONFIG=/usr/share/t1lib/t1lib.config

 XDG_CONFIG_DIRS=/etc/xdg:/etc/kde/xdg:/etc/xfce/xdg

 MINICOM=-c on

-MAIL=/var/spool/mail/root

-PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib64/java/bin:/usr/lib64/kde4/libexec:/usr/lib64/qt/bin:/usr/share/texmf/bin

-LC_COLLATE=C

-INPUTRC=/etc/inputrc

-PWD=/root

+PATH=/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin

+STY=2507.pts-0.LinuxPC

+_=/bin/env

+INPUTRC=/home/username/.inputrc

+PWD=/home/username

 JAVA_HOME=/usr/lib64/java

-LANG=en_US

 QT4DIR=/usr/lib64/qt

 KDEDIRS=/usr

 PS1=\u@\h:\w\$

-PS2=>

-SHLVL=1

+HISTCONTROL=erasedups

 HOME=/root

+COLORFGBG=15;default;0

+SHLVL=5

 LS_OPTIONS=-F -b -T 0 --color=auto

 LESS=-M

 LOGNAME=root

+WINDOW=12

 PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/lib64/pkgconfig

 LESSOPEN=|lesspipe.sh %s

+WINDOWPATH=7

+DISPLAY=:0.0

 G_BROKEN_FILENAMES=1

-_=/usr/bin/env

+COLORTERM=rxvt-xpm

+XAUTHORITY=/home/username/.Xauthority

Obviously a much different environment, as expected (see `man su`).

That line in login.defs does this:

Code:

$ ps ax | grep [-]su

14480 pts/17  S      0:00 -su

If there is an application or script that determines how it should act according to the name of the parent process, then you may have issues, but I don't know of any (possibly excepting init etc.) that would do such a thing. If you do, feel free to give some examples. It seems `su -` is acting as it should and it would be subprocesses that aren't...

OK, bearing in mind that the line in /etc/login.defs is commented out for all of this, I exited (which is to the console, not to a GUI login) and

Code:

log in as root

env | sort > /tmp/root_login

exit

log in as me

su -

env | sort > /tmp/root_su

diff /tmp/root_login /tmp/root_su

14d13

< HUSHLOGIN=FALSE

That's the only difference (other than who am i shows "me").

What happens is that invoking su - does all the environmental setup that is done from a "raw" login; profiles are invoked (/etc/profile and its cousins plus the user's .profile and .exrc files) and a prompt is displayed. Something like this:

Code:

pita-trona-/home/trona: su -

Password: 



When does summertime come to Minnesota, you ask?  Well, last year, I

think it was a Tuesday.



pita-root-/root:

All users on my systems are using Korn Shell and everybody gets these defaults (which they can -- and some do -- override in their .profile, .exrc or .kshrc files):

Code:

cat /etc/profile.d/ksh.sh

#!/bin/sh

#ident  "$Id$"

#

#      Name:          $Source$

#      Version:        $Revision$

#      Modified:      $Date$

#      Purpose:        set local environment variables for Korn Shell

#      Author:        T. N. Ronayne

#      Date:          1 Oct 2009

#      $Log$

# Set the HOST environment variable

export HOST="`uname -n`"

# Set ksh93 visual editing mode:

if [ "$SHELL" = "/bin/ksh" ]; then

#  VISUAL=emacs        # ugh

#  VISUAL=gmacs        # double ugh

  VISUAL=vi            # ah, elegance

fi

# Set a default shell prompt:

#PS1='`hostname`:`pwd`# '

# Do these anyway in case somebody uses a different shell

if [ "$SHELL" = "/bin/pdksh" ]; then

 PS1='! $ '

elif [ "$SHELL" = "/bin/ksh" ]; then

 PS1='${HOST}-${USER}-${PWD}: '

elif [ "$SHELL" = "/bin/zsh" ]; then

 PS1='%n@%m:%~%# '

elif [ "$SHELL" = "/bin/ash" ]; then

 PS1='$ '

else

 PS1='\u@\h:\w\$ '

fi

PS2='> '

export PS1 PS2

Everybody, that is, but one user that is comfortable with C-Shell (and uses applications and utilities that no other users do) so that user's environment is set differently (which is not germane so we won't look at it). However, executing su - thatuser starts up C-shell, sets the environment from /etc and the user's .login and .cshrc files. As desired. As expected.

This behavior is what I want so that when I invoke su - somebody I get their complete environment without inheriting anything of the environment I started in (and when I exit there's no corpses messing with my original environment).

Bottom line the behavior is different whether you comment out SU_NAME or leave it at the default; the diff above, I believe, demonstrates that pretty well. The comment in /etc/login.defs does not, I think, go quite far enough to clearly explain the effect of one way or the other.

Too, things may behave differently in BASH; don't know, don't like it, don't use it.

Hope this helps some.

Quote:

Bottom line the behavior is different whether you comment out SU_NAME or leave it at the default; the diff above, I believe, demonstrates that pretty well. The comment in /etc/login.defs does not, I think, go quite far enough to clearly explain the effect of one way or the other.

I haven't altered login.defs at all and I'm seeing the same behaviour as you are. Here's what I'v done :

Code:

login:root

env > login.txt

exit

login: user

su -

env > su-env.txt

diff login.txt su-env.txt 

7d6

< HUSHLOGIN=FALSE

This is all with the SU_NAME in login.defs left as default. I run bash as my shell however so possibly that's causing the difference between what I'm seeing and what you're reporting.