Nikos Chantziaras wrote:
> On 02/28/2010 05:57 AM, ubiquitous1980 wrote:
>> If I have logged in through sudo such as $ sudo su, when I then use man
>> pages, they are covered in "ESC". This does not occur when using normal
>> user accounts or the root account through su. Wondering what is going
>> on. Thanks.
>
> Some ENV variables are unset by sudo.
>
> But anyway, "sudo su" makes zero sense :P
>
>
sudo su makes sense if you want to use the root account while having the
root account locked. Some, like Ubuntu, do it for security reasons.
Not sure if they are valid, but I thought I would put this little
problem out there for someone to make comment on.

chrome://messenger/locale/messengercompose/composeMsgs.properties:

Nikos Chantziaras wrote:


On 02/28/2010 05:57 AM, ubiquitous1980 wrote:


If I have logged in through sudo such as $ sudo su, when I then use man
pages, they are covered in "ESC". This does not occur when using normal
user accounts or the root account through su. Wondering what is going
on. Thanks.


Some ENV variables are unset by sudo.

But anyway, "sudo su" makes zero sense :P




sudo su makes sense if you want to use the root account while having the
root account locked. Some, like Ubuntu, do it for security reasons.
Not sure if they are valid, but I thought I would put this little
problem out there for someone to make comment on.




I don't use sudo or su but I have seen this a time or two. I have no
clue why tho. It was a while ago but I was in a console at the time. I
usually use a Konsole within KDE. I don't recall ever seeing this
problem there.


I was curious but never thought is would be more than just me that saw this.

Dale

:-) :-)

On Sunday 28 February 2010 04.57:36 ubiquitous1980 wrote:
> If I have logged in through sudo such as $ sudo su, when I then use man
> pages, they are covered in "ESC". This does not occur when using normal
> user accounts or the root account through su. Wondering what is going
> on. Thanks.
And I have the exact opposite on one of my rigs. Viewing man pages as a normal
user and it get cluttered with ESC..., but view the same page after doing a
'sudo su -' everything is OK.
--
Dan Johansson, <http://www.dmj.nu>
************************************************** *
This message is printed on 100% recycled electrons!
************************************************** *

ubiquitous1980 wrote:
> If I have logged in through sudo such as $ sudo su, when I then use man
> pages, they are covered in "ESC". This does not occur when using normal
> user accounts or the root account through su. Wondering what is going
> on. Thanks.

Q: Have you tried "... su -" (the dash is important since it will read
the environment for root login otherwise the environment will be the
same as for current user).

http://lists.debian.org/debian-security/2006/07/msg00059.html

Best regards

Peter K

On Sun, 28 Feb 2010 13:06:43 +0800, ubiquitous1980 wrote:

> > Some ENV variables are unset by sudo.

You can alter that behaviour in /etc/sudoers. I have

Defaults:%wheel !env_reset

and don't see this.

> > But anyway, "sudo su" makes zero sense :P

> sudo su makes sense if you want to use the root account while having the
> root account locked.

The root account is hardly locked if you can log into it with sudo su
(or sudo screen) but sudo -s or sudo -i make more sense in this
situation.


--
Neil Bothwick

Politicians are like nappies
Both should be changed regularly, and for the same reason

Neil Bothwick wrote:
> On Sun, 28 Feb 2010 13:06:43 +0800, ubiquitous1980 wrote:
>
>
>>> Some ENV variables are unset by sudo.
>>>
>
> You can alter that behaviour in /etc/sudoers. I have
>
> Defaults:%wheel !env_reset
>
> and don't see this.
>
>
>>> But anyway, "sudo su" makes zero sense :P
>>>
>
>
>> sudo su makes sense if you want to use the root account while having the
>> root account locked.
>>
>
> The root account is hardly locked if you can log into it with sudo su
> (or sudo screen) but sudo -s or sudo -i make more sense in this
> situation.
>
>
>
localhost ubiquitous1980 # passwd -l root
Password changed.
localhost ubiquitous1980 # exit
exit
ubiquitous1980@localhost ~ $ su
Password:
su: Authentication failure
ubiquitous1980@localhost ~ $ sudo su
Password:
Your account has expired; please contact your system administrator
su: User account has expired
(Ignored)
localhost ubiquitous1980 #

pk wrote:
> ubiquitous1980 wrote:
>
>> If I have logged in through sudo such as $ sudo su, when I then use man
>> pages, they are covered in "ESC". This does not occur when using normal
>> user accounts or the root account through su. Wondering what is going
>> on. Thanks.
>>
>
> Q: Have you tried "... su -" (the dash is important since it will read
> the environment for root login otherwise the environment will be the
> same as for current user).
>
> http://lists.debian.org/debian-security/2006/07/msg00059.html
>
> Best regards
>
> Peter K
>
>
With "sudo su - " the man pages do not have ESC throughout. I have
learned sudo su from my ubuntu days and I am only guessing that this is
bad practice and that the correct command is $ sudo su -

Thanks

Damien

ubiquitous1980 wrote:

>> http://lists.debian.org/debian-security/2006/07/msg00059.html

> With "sudo su - " the man pages do not have ESC throughout. I have
> learned sudo su from my ubuntu days and I am only guessing that this is
> bad practice and that the correct command is $ sudo su -

No need to guess. Messing with superuser privileges without a proper
superuser environment (paths etc.) is considered bad from a security
point of view; for instance, an malicious application could be installed
in your user home dir, prepend the path to this to your local user $PATH
and whenever you do "su" (without -) you could invoke this app with
superuser privileges...
So to summarize: The link above (debian.org) explains it quite well and
yes, I would say it's a bad habit to omit -. :-)

Best regards

Peter K

pk wrote:
> ubiquitous1980 wrote:
>
>
>>> http://lists.debian.org/debian-security/2006/07/msg00059.html
>>>
>
>
>> With "sudo su - " the man pages do not have ESC throughout. I have
>> learned sudo su from my ubuntu days and I am only guessing that this is
>> bad practice and that the correct command is $ sudo su -
>>
>
> No need to guess. Messing with superuser privileges without a proper
> superuser environment (paths etc.) is considered bad from a security
> point of view; for instance, an malicious application could be installed
> in your user home dir, prepend the path to this to your local user $PATH
> and whenever you do "su" (without -) you could invoke this app with
> superuser privileges...
> So to summarize: The link above (debian.org) explains it quite well and
> yes, I would say it's a bad habit to omit -. :-)
>
> Best regards
>
> Peter K
>
>
Thanks for your explanation and I will remember this lesson.]

Thanks,

Damien

pk wrote:
> ubiquitous1980 wrote:
>
>
>>> http://lists.debian.org/debian-security/2006/07/msg00059.html
>>>
>
>
>> With "sudo su - " the man pages do not have ESC throughout. I have
>> learned sudo su from my ubuntu days and I am only guessing that this is
>> bad practice and that the correct command is $ sudo su -
>>
>
> No need to guess. Messing with superuser privileges without a proper
> superuser environment (paths etc.) is considered bad from a security
> point of view; for instance, an malicious application could be installed
> in your user home dir, prepend the path to this to your local user $PATH
> and whenever you do "su" (without -) you could invoke this app with
> superuser privileges...
> So to summarize: The link above (debian.org) explains it quite well and
> yes, I would say it's a bad habit to omit -. :-)
>
> Best regards
>
> Peter K
>
>
Investigated this further...

With su, PATH=/sbin:/bin:/usr/sbin:/usr/bin

With sudo su, PATH=/sbin:/bin:/usr/sbin:/usr/bin

With sudo su -,
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4:/usr/lib64/subversion/bin

This final PATH is the same as my user's account. I thought that this
would be the other way around, and that with $ sudo su - I would expect
the normal root path as to prevent a malicious program settinga path
and allowing execution without identifying its specific location at the CLI.

Perhaps I am confused.

Thanks

Damien