[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19990421: superuser not so super

Jennie,
When you use su, you have 2 options:

su mcidas:
This will effectively become the user mcidas with permissions etc, but
will still have the environment from your previous user shell.

su - mcidas:
when you add the -, this tells the su shell to treat the session as a "login"
shell, and sources the environment and sets up the shell for the su'd
user as it would if you logged in.

Hope that clears up the man page stuff.

Steve Chiswell
Unidata User SUpport


>From: "Jennie L. Moody" <address@hidden>
>Organization: .
>Keywords: 199904211525.JAA10084

>
>Learned something useful lastnight (probably was told
>it before, maybe  more than once, but... this was 
>active learning).
>
>Several things preceded this but ultimately I
>super-user'ed into mcidas (aha!)
>
>o dmap.k S T FORM=ALL found several files (TERMCHAR, SYSIMAGE,
>  etc. the usual suspects) in wrong places (as expected)
>  (/home/mcidas/workdata, /home/mcidas/data, 
>  deleted all these 
>
>o after deletions, just to make sure, ran dmap.k again
>  several of the files showed up again...
>  with a new time stamp... it was clear the running
>  of dmap itself was creating this instance of the offending
>  files.
>
>o exited from the su. logged in as user mcidas.
>  removed the bad files, ran dmap.k, THIS time
>  it appropriately found only one instance of these
>  files in the /home/mcidas/.mctmp directory (where they
>  should have been).
>
>
>Read man page on su on my system:
>-----
>     su creates a new shell process that has the real and  effec-
>     tive user ID, group IDs, and supplementary group list set to
>     those of the specified username.  The new shell will be  the
>     shell  specified  in  the shell field of username's password
>     file entry (see  passwd(4)).   If  no  shell  is  specified,
>     /usr/bin/sh  is  used (see sh(1)).
>
>     The following statements are true only if either /usr/bin/sh
>     or  NULL  is  named  in  the  specified user's password file
>     entry.  If the first argument to su is a ' - '  (dash),  the
>     environment  is passed along unchanged, as if the user actu-
>     ally logged  in  as  the  specified  user.   Otherwise,  the
>     environment  is  passed  along, with the exception of $PATH,
>     which is controlled by PATH and SUPATH in etc/default/su.
>-----
>Not exactly sure what this means if /bin/ksh is specified in
>the password file entry, but clearly the environment does not
>get set right, so maybe the file .variable.ksh doesn't get 
>sourced?  
>
>Anyway, I now see SU doesn't get the full environment of the user
>(at least not when using the k-shell).
>I don't even want to recall how many times I have su'd into
>mcidas to check something (sometimes to verify redirections,
>sometimes to run the dmap command).....Seems I had the 
>potential to create problems for myself everytime!
>
>lesson: from now on, log in to do things
>
>
>Jennie
>


>From address@hidden  Wed Apr 21 14:49:09 1999
Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9])
        by unidata.ucar.edu (8.8.8/8.8.8) with SMTP id OAA19164
        for <address@hidden>; Wed, 21 Apr 1999 14:49:09 -0600 (MDT)
Organization: .
Keywords: 199904212049.OAA19164
Received: from windfall.evsc.virginia.edu by mail.virginia.edu id aa13031;
          21 Apr 99 16:49 EDT
Received: (from jlm8h@localhost) by windfall.evsc.Virginia.EDU (8.8.5/8.6.6) id 
QAA29140; Wed, 21 Apr 1999 16:49:01 -0400 (EDT)
Date: Wed, 21 Apr 1999 16:49:01 -0400 (EDT)
From: "Jennie L. Moody" <address@hidden>
Message-Id: <address@hidden>
X-Mailer: Mail User's Shell (7.2.6 03/03/1995)
To: Unidata Support <address@hidden>
Subject: Re: 1999421: superuser not so super
Cc: address@hidden

On Apr 21, 12:30, Unidata Support wrote:
> Subject: 1999421: superuser not so super
> >Organization: UVa
> >Keywords:  199904211525.JAA10084 McIDAS su
> 
> Jennie,
> 
> I just wanted to echo Chiz's comment on 'su' and 'su -'.  Doing an
> 'su -' to a user account is virtually identical to loggin in as the
> user, so this is would be the easiest option for you to use.

Right, tried it.  This is one of those things I know I knew and
then forgot (sigh). 

> 
> So, it may be possible that su'ing could have been the problem all
> along?  Scary thought!  I was kind of wondering why you were
> experiencing this problem repeatedly while we have not seen the same in
> a _very_ long time here at the UPC.
> 

> It will be interesting to see if you run into the same problems after you
> stop 'su'ing to the 'mcidas' account.  I am sure that you will do so, but
> I feel like I have to add that you need to relate this to Owen and Tony.
> 

Possible, but I'm not certain of it....I did talk with Owen and Tony
about this, but I have to state that I also went through the su log
and can see that *I* am the only one doing this (and not all that
frequently, although interestingly enough, the frequency went up
after you told me to run dmap.k as user mcidas to search the entire
directory structure for offending files ;-)....I would make them in 
the process, and then delete them I guess, but if I ever did a *double
check*, or anything else, I would have created an instance of 
offending files that should have gone to .mctmp).  I would also guess
that just as often as I su'd in I telnet'd in...kinda random, huh. 

No one to blame but myself! (not that I go around scapegoating 
students or anything anyway) I will happily take all the blame if 
this really is *it*.  (I won't hold my breath).

Jennie

> Tom
> -- End of excerpt from Unidata Support <address@hidden>