LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 02-24-2011, 09:44 AM   #1
Robert.Thompson
Member
 
Registered: Nov 2009
Location: Montreal, Quebec, Canada
Distribution: Slackware 13.37 -32 Bit
Posts: 578

Rep: Reputation: 49
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,

Last edited by Robert.Thompson; 02-24-2011 at 09:54 AM.
 
Old 02-24-2011, 10:54 AM   #2
DeTomasso
LQ Newbie
 
Registered: Oct 2010
Location: Elbląg
Distribution: Slackware64
Posts: 10

Rep: Reputation: 2
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.
 
1 members found this post helpful.
Old 02-24-2011, 11:12 AM   #3
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,118

Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
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.
 
1 members found this post helpful.
Old 02-24-2011, 02:21 PM   #4
Keith Hedger
Member
 
Registered: Jun 2010
Location: Devon,UK
Distribution: Linux From Scratch, Slackware64,
Posts: 993

Rep: Reputation: 214Reputation: 214Reputation: 214
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!
 
1 members found this post helpful.
Old 02-24-2011, 04:14 PM   #5
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,574

Rep: Reputation: 463Reputation: 463Reputation: 463Reputation: 463Reputation: 463
Quote:
Originally Posted by tronayne View Post
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."
 
Old 02-24-2011, 04:17 PM   #6
dive
Senior Member
 
Registered: Aug 2003
Location: UK
Distribution: Slackware
Posts: 3,211

Rep: Reputation: 293Reputation: 293Reputation: 293
Quote:
Originally Posted by Richard Cranium View Post
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.
 
Old 02-24-2011, 05:42 PM   #7
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,118

Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
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.

Last edited by tronayne; 02-24-2011 at 05:44 PM. Reason: Fumble finger
 
Old 02-24-2011, 07:01 PM   #8
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,297

Rep: Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722
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...
 
Old 02-25-2011, 08:00 AM   #9
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,118

Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
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.
 
0 members found this post helpful.
Old 02-25-2011, 09:19 AM   #10
bgeddy
Senior Member
 
Registered: Sep 2006
Location: Liverpool - England
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810

Rep: Reputation: 227Reputation: 227Reputation: 227
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.
 
  


Reply

Tags
application, installation, log, questions, root, user


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
User log out as Root 5577 Linux - Security 5 06-01-2006 09:41 AM
How to enable root to run graphical application in user log in xgreen Slackware 4 03-07-2005 07:39 AM
Cant only log in as root after user log-in. ADJenkins Linux - General 2 11-17-2004 05:18 PM
Log Out root Then Log In As Other User xtremcoder Linux - General 4 10-05-2004 12:01 AM
How to Run an Application as root without a log off? shassouneh Linux - Software 16 06-03-2002 03:41 AM


All times are GMT -5. The time now is 11:05 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration