subject:"\[DNG\] New behaviour under Devuan."


Le 23/09/2017 à 22:26, Renaud (Ron) OLGIATI a écrit :

Changing PS1 in the relevant .bashrc changes colours both in  XFCE-console and 
in tty


Yes. But this isn't what Steve does. He changes the colour profile 
of the xterm, depending of what command he wants to run.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.


Le 23/09/2017 à 21:56, Steve Litt a écrit :

On Sat, 23 Sep 2017 21:45:04 +0200
Didier Kryn  wrote:


Le 23/09/2017 à 20:20, Steve Litt a écrit :

What a pity there isn't a visual indicator that you are weilding
root authority like, I don't know, maybe the bash shell prompt
ending character changing from "$" to "#".

That's not enough for me. When I open a terminal intended to be
either root or on a different machine, I open a terminal that's
white on red background. When I open a terminal intended to be me
on my local machine, it's black on white background. This has saved
me some pretty bad mistakes over the years.
 

  Means you must have one terminal profile for every location you
ssh to.

No it doesn't. If I'm sshed anywhere, it's a red background, same as if
I'm root. Basically, if my terminal is black on white, everything's
"business as usual." If it's white on dark red, watch out, check
everything, check twice.


And you forbid yourself to use su or ssh from the command
line, because this doesn't change the color scheme of the terminal.

No forbidding. I simply run a red terminal if I'm going to ssh. It's
perhaps a little discipline, but no biggy.

And now that you mention it, I could have shellscripts ssht and sut
that spawn a red terminal and then run the rest of the command on the
red terminal.


  It's pretty heavy to manage all the necessary terminal profiles
- I used gnome-terminal when I experimented with this method, a dozen
years ago. I eventually found it complicated my life a lot.

I don't think I'm taking it as far as you did. I have two terminals:
black on white means "business as usual", while white on dark
red means BEWARE, WATCH OUT, DANGER, PELEGRO, ACHTUNG.


Well, I think we've got a comprehensive review of the strategies 
used to remind the user s?he's acting as root, and they all rely on colour.


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On Sat, 23 Sep 2017 21:45:04 +0200
Didier Kryn  wrote:

> And you forbid yourself to use su or ssh from the command line, 
> because this doesn't change the color scheme of the terminal.

? ? ? ?

Changing PS1 in the relevant .bashrc changes colours both in  XFCE-console and 
in tty
 
Cheers,
 
Ron.
-- 
  Anyone who goes to a psychiatrist
   ought to have his head examined.
  -- Samuel Goldwyn

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-23 Thread Steve Litt

On Sat, 23 Sep 2017 21:45:04 +0200
Didier Kryn  wrote:

> Le 23/09/2017 à 20:20, Steve Litt a écrit :
> >> What a pity there isn't a visual indicator that you are weilding
> >> root authority like, I don't know, maybe the bash shell prompt
> >> ending character changing from "$" to "#".  
> > That's not enough for me. When I open a terminal intended to be
> > either root or on a different machine, I open a terminal that's
> > white on red background. When I open a terminal intended to be me
> > on my local machine, it's black on white background. This has saved
> > me some pretty bad mistakes over the years.
> > 
> 
>  Means you must have one terminal profile for every location you
> ssh to. 

No it doesn't. If I'm sshed anywhere, it's a red background, same as if
I'm root. Basically, if my terminal is black on white, everything's
"business as usual." If it's white on dark red, watch out, check
everything, check twice.

> And you forbid yourself to use su or ssh from the command
> line, because this doesn't change the color scheme of the terminal.

No forbidding. I simply run a red terminal if I'm going to ssh. It's
perhaps a little discipline, but no biggy.

And now that you mention it, I could have shellscripts ssht and sut
that spawn a red terminal and then run the rest of the command on the
red terminal.

> 
>  It's pretty heavy to manage all the necessary terminal profiles
> - I used gnome-terminal when I experimented with this method, a dozen
> years ago. I eventually found it complicated my life a lot.

I don't think I'm taking it as far as you did. I have two terminals:
black on white means "business as usual", while white on dark
red means BEWARE, WATCH OUT, DANGER, PELEGRO, ACHTUNG.

 SteveT

Steve Litt
September 2017 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.


Le 23/09/2017 à 20:20, Steve Litt a écrit :

What a pity there isn't a visual indicator that you are weilding root
authority like, I don't know, maybe the bash shell prompt ending
character changing from "$" to "#".

That's not enough for me. When I open a terminal intended to be either
root or on a different machine, I open a terminal that's white on red
background. When I open a terminal intended to be me on my local
machine, it's black on white background. This has saved me some pretty
bad mistakes over the years.
  


Means you must have one terminal profile for every location you ssh 
to. And you forbid yourself to use su or ssh from the command line, 
because this doesn't change the color scheme of the terminal.


It's pretty heavy to manage all the necessary terminal profiles - I 
used gnome-terminal when I experimented with this method, a dozen years 
ago. I eventually found it complicated my life a lot.


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.


Le 23/09/2017 à 19:58, Miroslav Rovis a écrit :

(as further above) only if targetpw is also set...


Think I've got it now :-)


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-23 Thread Steve Litt

On Fri, 22 Sep 2017 23:35:37 -0700
Rick Moen  wrote:

> Quoting Hendrik Boom (hend...@topoi.pooq.com):
> 
> > The problem with su is that you may forget you are superuser and
> > start doing dangerous things,
> > 
> > That's it.  
> 
> What a pity there isn't a visual indicator that you are weilding root
> authority like, I don't know, maybe the bash shell prompt ending
> character changing from "$" to "#".

That's not enough for me. When I open a terminal intended to be either
root or on a different machine, I open a terminal that's white on red
background. When I open a terminal intended to be me on my local
machine, it's black on white background. This has saved me some pretty
bad mistakes over the years.

SteveT

Steve Litt
September 2017 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On 170923-19:39+0200, Antoine wrote:
> On Sat, Sep 23, 2017 at 03:12:23PM +, Miroslav Rovis wrote:
> > (...)
> > 
> > Anybody got a quick tips page somewhere to find the exact color codes? Else 
> > I'm
> > out of the discussion for now. Too much effort... (and other work awaiting 
> > me,
> > I'm not lazy, but resources of mind energy not limitless, this has started
> > feeling like mind building exercize --compared to body building--...).
> > 
> > Regards!
> > -- 
> > Miroslav Rovis
> > Zagreb, Croatia
> > https://www.CroatiaFidelis.hr
> 
> You can find the whole list of colours (and many other control codes) in the 
> (4)console_codes manpage.
> 
> - Antoine
Great! Thanks, more mind building exercise --comparison to body building--
follows, immediately or later. :-)

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

Also a reply by Renaud, further in bottom (with the color codes! :-) )

On 170923-18:50+0200, Didier Kryn wrote:
> Le 23/09/2017 à 16:54, Miroslav Rovis a écrit :

The targetpw, three lines below is key to understanding my query that I posted
regarding the ability to forget the root password when issuing the "sudo su -l"
command, as Didier wrote in a previous email.
> > 
> > # Allow members of group sudo to execute any command
> > %sudo   ALL=(ALL:ALL) ALL
> > Defaults targetpw
> > mr  ALL=(ALL:ALL) ALL
> > 
...
> 
> I don't know what "Default targetpw" is. Never used that.

From "man sudoers":
 targetpw  If set, sudo will prompt for the password of the user
   specified by the -u option (defaults to root) instead of
   the password of the invoking user when running a command
   or editing a file.  Note that this flag precludes the
   use of a uid not listed in the passwd database as an
   argument to the -u option.  This flag is off by default.

So, no forgetting of the root password when becoming root via sudo is
impossible in my configuration!

> Here are my
> only defaults:
> 
> Defaultsenv_reset
> Defaultsenv_keep=EDITOR
> Defaults
> secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
> Defaults editor = 
> /usr/bin/nano:/usr/bin/vim:/usr/bin/vi:/usr/bin/emacs:/usr/bin/jed:/usr/bin/mg:/usr/bin/zile
> 
> You need to pass the user's editor for use with sudoedit and visudo, but,
> for security, you must only allow known editors.
> 
> I don't give permissions to groups, only to some persons, based on necessity
> and competence. For this I use "UserAlias" and "CmndAlias" and I recommend
> it.
> 
> 
> User_Alias  ELOGADMIN = gahs, kryn, kaneda, neff
> User_Alias  PYTHONADM = kaneda
> ...
> Cmnd_Alias  VIEW = /bin/more, /usr/bin/less, /bin/grep
> Cmnd_Alias  HIDE = !/bin/more *shadow, !/usr/bin/less *shadow,
> !/bin/grep *shadow
> ...
> ELOGADMIN THIS_HOST = (elog)ALL
> SYSADMIN  THIS_HOST = (root)  NOPASSWD: /bin/ls, VIEW, HIDE
> SYSADMIN  THIS_HOST = (root) /usr/sbin/service, /bin/mount
> SUPER ALL   = (root)ALL
> 
> > 
> > > Sudo does have its benefits but it must be used to control user
> > > privileges. Granting all commands to every user is the opposite of
> > > what security means.
> > As above, the targetpw helps against that...
> > 
> > And I don't get what Didier means. Citation below is manually pasted in.
> > On 170923-11:10+0200, Didier Kryn wrote:
> > > Le 23/09/2017 à 08:49, Alessandro Selli a écrit :
> > > > He's actually right: the least the superuser's password is used, 
> > > > the better
> > > > and the safer.

This is what I surely would never understand, because in my configuration it
could never happen:
> > >  Yep, you can invoke 'sudo su -l'; that's su without the root 
> > > password.
> > > It helps you forget the root password.
> > > 
> > >  Didier
> > Whatever do you mean that command above "helps you forget the root 
> > password"?
> See at the bottom :-)
> > 
> > Let me use grsecurity-kernel's exec_logging and audit chdir features ofmy
> > (miniply github repo) grsecurity-hardened kernel to explain my query. It was
> > originally 44 lines, and 44 lines of quick truth, but I reduced it to
> > 20-something lines, as some of it is not relevant to here, and I 
> > deliberately
> > modified some info, where not relevant only. But, I wrapped all the lines 
> > for
> > email web, and inserted space btwn lines. Here:
> > 
> > The first 8 lines is me starting an xterm to test that Didier's command:
> > 
> > [...]
> > So what about and how that command "helps you forget the root password"? I 
> > did
> > have to type my root password right before I became "uid/euid:0/0 
> > gid/egid:0/0"
> > having started as only "uid/euid:1000/1000 gid/egid:1000/1000"...
> > 
> > Regards?
> > 
> Sorry but I'm lost in all these logs. What I meant is:
I figured out what you meant, as you can read above.

However, those logs --readers see my previous email-- demonstrate, and kind of
with forensical certainty, that I switched to root, while previously having
been only user mr, and all the events around it, because that grsecurity
feature logs all exec's and chdir's in a system. Occasionally that is a superb
feature you could only dream of, but it is available only in
grsecurity-kernels, and the miniply's unofficial-grsecurity kernel appears to
me very reliable, even though the original developers left months ago --though
this statement of mine is still to be confirmed with more use/more testing!

Yet, if I didn't have targetpw I would anyway become root under different
configuration... i.e., if conf such, with user's own password. So the logs
don't prove much at all in this case... It would take strace or keyboard logger
to prove what exactly happened... Dear God, it's all

Re: [DNG] New behaviour under Devuan.

2017-09-23 Thread Antoine

On Sat, Sep 23, 2017 at 03:12:23PM +, Miroslav Rovis wrote:
> (...)
> 
> Anybody got a quick tips page somewhere to find the exact color codes? Else 
> I'm
> out of the discussion for now. Too much effort... (and other work awaiting me,
> I'm not lazy, but resources of mind energy not limitless, this has started
> feeling like mind building exercize --compared to body building--...).
> 
> Regards!
> -- 
> Miroslav Rovis
> Zagreb, Croatia
> https://www.CroatiaFidelis.hr

You can find the whole list of colours (and many other control codes) in the 
(4)console_codes manpage.

- Antoine

-- 
Friends are people who know you and who like you anyway.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.


Le 23/09/2017 à 17:12, Miroslav Rovis a écrit :

But I'll need to take a deep breath to figure out the nice Bash lines
that you sent to the list. :-)


I didn't invent this totally; i picked it from some default Debian 
.bashrc years ago. I bet you can still find at least part of it in the 
default .bashrc, although commented out. All these \[ escape sequences 
are recognized by the terminal / terminal emulator to set the color. I 
think they come from the vt100 or a descendent.

The prompt above writes
the chroot name - if any - in the default color, between parentheses,
then "root@hostname:" in red for root  (green for me and  magenta for 
www-data),

then current directory, in blue,
then "# " in the default color

Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

Le 23/09/2017 à 16:54, Miroslav Rovis a écrit :

(Also replying to Didier Kryn, because it is related to my question put
following Edward email below, however, too much Edward's text missing in
Didier's reply.)

On 170923-09:15+0200, Edward Bartolo wrote:

Quote: "He's actually right: the least the superuser's password is
used, the better
and the safer."

Granted, but sudo as configured in Ubuntu makes the use of a superuser
password pointless. Sudo is configured to be a wide wide open door
leading to any part of a computer's 'household'. In other words, sudo
with the infamous 'user ALL=(ALL)' in /etc/sudoers makes root
practically like any other user.

I do have it (that exact section of my /etc/sudoers follows):

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
Defaults targetpw
mr ALL=(ALL:ALL) ALL

Does the "Defaults targetpw", and a really strong password still keep me safe,
sudo-wise (not talking other measures: iptables, grsecurity, just sudo-wise)?

I am (as user mr) both:

# cat /etc/group | grep sudo
sudo:x:27:mr
#

member of group sudo, and have those lines under "Defaults targetpw". Really
interested about opinions/advice: safe, as far as sudo goes?

I don't know what "Default targetpw" is. Never used that. Here are
my only defaults:

Defaultsenv_reset
Defaultsenv_keep=EDITOR
Defaults
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults editor =
/usr/bin/nano:/usr/bin/vim:/usr/bin/vi:/usr/bin/emacs:/usr/bin/jed:/usr/bin/mg:/usr/bin/zile

You need to pass the user's editor for use with sudoedit and visudo,
but, for security, you must only allow known editors.

I don't give permissions to groups, only to some persons, based on
necessity and competence. For this I use "UserAlias" and "CmndAlias" and
I recommend it.

User_Alias ELOGADMIN = gahs, kryn, kaneda, neff
User_Alias PYTHONADM = kaneda
...
Cmnd_Alias VIEW = /bin/more, /usr/bin/less, /bin/grep
Cmnd_Alias HIDE = !/bin/more *shadow, !/usr/bin/less *shadow,
!/bin/grep *shadow

...
ELOGADMIN THIS_HOST = (elog)ALL
SYSADMIN THIS_HOST = (root) NOPASSWD: /bin/ls, VIEW, HIDE
SYSADMIN THIS_HOST = (root) /usr/sbin/service, /bin/mount
SUPER ALL = (root)ALL

Sudo does have its benefits but it must be used to control user
privileges. Granting all commands to every user is the opposite of
what security means.

As above, the targetpw helps against that...

And I don't get what Didier means. Citation below is manually pasted in.
On 170923-11:10+0200, Didier Kryn wrote:

Le 23/09/2017 à 08:49, Alessandro Selli a écrit :

He's actually right: the least the superuser's password is used, the better
and the safer.

Yep, you can invoke 'sudo su -l'; that's su without the root password.
It helps you forget the root password.

Didier

Whatever do you mean that command above "helps you forget the root password"?

See at the bottom :-)

Let me use grsecurity-kernel's exec_logging and audit chdir features ofmy
(miniply github repo) grsecurity-hardened kernel to explain my query. It was
originally 44 lines, and 44 lines of quick truth, but I reduced it to
20-something lines, as some of it is not relevant to here, and I deliberately
modified some info, where not relevant only. But, I wrapped all the lines for
email web, and inserted space btwn lines. Here:

The first 8 lines is me starting an xterm to test that Didier's command:

[...]
So what about and how that command "helps you forget the root password"? I did
have to type my root password right before I became "uid/euid:0/0 gid/egid:0/0"
having started as only "uid/euid:1000/1000 gid/egid:1000/1000"...

Regards?

Sorry but I'm lost in all these logs. What I meant is:
1) if you allow yourself in the sudoers file to run 'su' as root, then
you never need the root password anymore; you use yours instead.
2) if you never need the root password anymore then you might quickly
forget it, unless you have written it somewhere. But, since you don't
need it, one can argue it doesn't matter... I leave it to your apreciation.

One nice thing with sudo is that it doesn't ask the password
everytime you invoke it. Note that you can even give yourself the
permission to run su without a password:

mr all = (root) NOPASSWD: /bin/su

I wouldn't recommend it :-)

Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

Also thanks for the quick replies, one from Renaud, in other emails.

But... (see below)...

On 170923-16:24+0200, Didier Kryn wrote:
> Le 23/09/2017 à 15:50, Miroslav Rovis a écrit :
> > On 170923-19:01+1000, Erik Christiansen wrote:
> > > On 23.09.17 10:15, Arnt Karlsen wrote:
> > > > ..I still miss and prefer the S.u.S.E.-5.2 way, root had a
> > > > nice red background color in xterms, fairly hard to miss.
> > > If the '#' and "root@hostname" escape the attention of a person
> > > entrusted with root privileges, then why not make the root prompt bright 
> > > red:
> > > 
> > > root@ratatosk:/home/erik# export PS1="\[\033[1;31m\]\u@\h:\W\$ 
> > > \[\033[0;0m\]"
> > Useful. But in which file do you stick it, you didn't say? ~/.bashrc ?
...
> > Find this wrong notion engraved, (lets put it mildly), in the comment at 
> > line
> > 45 of:
> > 
> > /etc/skel/.bashrc
> > 
...
> > but it will be available in the www.mail-archives.com, right after the 
> > message
> > to which I'm replying:
> > Re: [DNG] New behaviour under Devuan.
> > https://www.mail-archive.com/dng@lists.dyne.org/msg17863.html
> > 
> > if I'm not mistaken.
I wasn't much mistaken :-) It's relatively close to there:

[ same title as this email ]
https://www.mail-archive.com/dng@lists.dyne.org/msg17871.html
and the _bashrc.gz is at:
https://www.mail-archive.com/dng@lists.dyne.org/msg17871/_bashrc.gz
( whoever runs Mail-Archive.COM, does a good job )

(we're not at the "But... " yet :-) )
> > 
...
> > 46c46
> > < #force_color_prompt=yes
> > ---
> > > force_color_prompt=yes
> > 113a114,124
> > [...]
> > 
> > it appears that I set:
> > force_color_prompt=yes
> > in my ~/.bashrc . And that actually gives me color'ed mr@gdOv:~$ (I'm not an
> > expert as I often admit.)
> 
> I always use color, as you. The statement that prompt is more important
> than command output is just plain wrong. I use the same color as you (green
> for me and red for root), plus other fancy colours for other system
> usernames (eg www-data). It is very important also to remind you when you
> are in a chroot. Here is my prompt for root (note the color list in the
> comment):
> 
> 
> if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
> debian_chroot=$(cat /etc/debian_chroot)
> fi
> 
> # set a fancy prompt (non-color, unless we know we "want" color)
> # \[\033[01;XXm\] changes the color
> # with XX= 30->black-bold, 31->red, 32->green, 33->yellow, 34->blue,
> 35->cyan
> # and  \[\033[00m\] to return to the default color
> case "$TERM" in
> xterm*)
> PS1='${debian_chroot:+($debian_chroot)}\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
> '
> ;;
> *)
> PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
> ;;
> esac
> 
> 
> Cheers.
> Didier

Thanks!

But I'll need to take a deep breath to figure out the nice Bash lines that you
sent to the list. :-)

Anybody got a quick tips page somewhere to find the exact color codes? Else I'm
out of the discussion for now. Too much effort... (and other work awaiting me,
I'm not lazy, but resources of mind energy not limitless, this has started
feeling like mind building exercize --compared to body building--...).

Regards!
-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.


Le 23/09/2017 à 15:50, Miroslav Rovis a écrit :

On 170923-19:01+1000, Erik Christiansen wrote:

On 23.09.17 10:15, Arnt Karlsen wrote:

..I still miss and prefer the S.u.S.E.-5.2 way, root had a
nice red background color in xterms, fairly hard to miss.

If the '#' and "root@hostname" escape the attention of a person
entrusted with root privileges, then why not make the root prompt bright red:

root@ratatosk:/home/erik# export PS1="\[\033[1;31m\]\u@\h:\W\$ \[\033[0;0m\]"

Useful. But in which file do you stick it, you didn't say? ~/.bashrc ?
  

OK, that reverted the '#' to '$', presumably because I'd su-ed, rather
than logged in as root. (\$ => '#' for uid==0, else '$')

As all my xterms are yellow on darkslategrey, one bright red prompt
cannot be missed, even from the other side of the room.

However, the issue is somebody, origianally in Debian of course, decided colors
were distractful for users, and the default is no color in the prompt.

Find this wrong notion engraved, (lets put it mildly), in the comment at line
45 of:

/etc/skel/.bashrc

and it reads (the subject of the sentece added by me):
[color] turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt

It isn't so in my system, because I detected that and changed it. And root is
still not color'ed, but normal user is now green, which is enough for me to
know which terminal windows in my X are root. Simply: "root@gdOv:/home/mr#"
without color, is not enough. But when user "mr@gdOv:~$" is in color green,
which happens because I uncommented where it reads (now the first part of that
comment, along with the overlapping part) in the /etc/skel/.bashrc:

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user:

...So, when the user "mr@gdOv:~$" is in color green, I can't anymore miss where
I'm root instead.

I think in most of people's boxen the default is set, i.e. no color prompt,
which has these lines from /etc/skel/.bashrc commented out (but I don't
remember with certainty, and also read on if it's another change that does it
in fact):

if [ -n "$force_color_prompt" ]; then
 if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
 # We have color support; assume it's compliant with Ecma-48
 # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
 # a case would tend to support setf rather than setaf.)
 color_prompt=yes
 else
 color_prompt=
 fi
fi

And they read like the above in mine /etc/skel/.bashrc .
  
Attaching the /etc/skel/.bashrc as _bashrc.gz . It likely won't get to the

Lurker archives, attachments are not allowed in, other than text attachments,
but it will be available in the www.mail-archives.com, right after the message
to which I'm replying:
Re: [DNG] New behaviour under Devuan.
https://www.mail-archive.com/dng@lists.dyne.org/msg17863.html

if I'm not mistaken.

Interested reader can compare my /etc/skel/.bashrc if they have missing color
in their terminals in Xorg (open the attachment where available)):

_bashrc.gz

However, it might be another bit of code, thanks to which I have color'ed
terminal prompt as regular user... Looking up this diff:

mr@gdOv:~$ diff /etc/skel/.bashrc .bashrc
40c40
< xterm-color|*-256color) color_prompt=yes;;
---

 xterm-color) color_prompt=yes;;

46c46
< #force_color_prompt=yes
---

force_color_prompt=yes

113a114,124
[...]

it appears that I set:
force_color_prompt=yes
in my ~/.bashrc . And that actually gives me color'ed mr@gdOv:~$ (I'm not an
expert as I often admit.)


I always use color, as you. The statement that prompt is more 
important than command output is just plain wrong. I use the same color 
as you (green for me and red for root), plus other fancy colours for 
other system usernames (eg www-data). It is very important also to 
remind you when you are in a chroot. Here is my prompt for root (note 
the color list in the comment):



if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
# \[\033[01;XXm\] changes the color
# with XX= 30->black-bold, 31->red, 32->green, 33->yellow, 34->blue, 
35->cyan

# and  \[\033[00m\] to return to the default color
case "$TERM" in
xterm*)
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ 
'

;;
*)
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
;;
esac


Cheers.
Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On Sat, 23 Sep 2017 13:50:31 +
Miroslav Rovis  wrote:

> Useful. But in which file do you stick it, you didn't say? ~/.bashrc ?

I stick the root ones in the relevant /root/.bashrc, and in ~/.bashrc for the 
user.
 
Cheers,
 
Ron.
-- 
  If God didn't want women to be looked at,
 He would have made 'em ugly.
  -- Robert A. Heinlein

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On 170923-19:01+1000, Erik Christiansen wrote:
> On 23.09.17 10:15, Arnt Karlsen wrote:
> > ..I still miss and prefer the S.u.S.E.-5.2 way, root had a 
> > nice red background color in xterms, fairly hard to miss.
> 
> If the '#' and "root@hostname" escape the attention of a person
> entrusted with root privileges, then why not make the root prompt bright red:
> 
> root@ratatosk:/home/erik# export PS1="\[\033[1;31m\]\u@\h:\W\$ \[\033[0;0m\]"

Useful. But in which file do you stick it, you didn't say? ~/.bashrc ?

> OK, that reverted the '#' to '$', presumably because I'd su-ed, rather
> than logged in as root. (\$ => '#' for uid==0, else '$')
> 
> As all my xterms are yellow on darkslategrey, one bright red prompt
> cannot be missed, even from the other side of the room.

However, the issue is somebody, origianally in Debian of course, decided colors
were distractful for users, and the default is no color in the prompt.

Find this wrong notion engraved, (lets put it mildly), in the comment at line
45 of:

/etc/skel/.bashrc

and it reads (the subject of the sentece added by me):
[color] turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt

It isn't so in my system, because I detected that and changed it. And root is
still not color'ed, but normal user is now green, which is enough for me to
know which terminal windows in my X are root. Simply: "root@gdOv:/home/mr#"
without color, is not enough. But when user "mr@gdOv:~$" is in color green,
which happens because I uncommented where it reads (now the first part of that
comment, along with the overlapping part) in the /etc/skel/.bashrc:

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user:

...So, when the user "mr@gdOv:~$" is in color green, I can't anymore miss where
I'm root instead.

I think in most of people's boxen the default is set, i.e. no color prompt,
which has these lines from /etc/skel/.bashrc commented out (but I don't
remember with certainty, and also read on if it's another change that does it
in fact):

if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi

And they read like the above in mine /etc/skel/.bashrc .

Attaching the /etc/skel/.bashrc as _bashrc.gz . It likely won't get to the
Lurker archives, attachments are not allowed in, other than text attachments,
but it will be available in the www.mail-archives.com, right after the message
to which I'm replying:
Re: [DNG] New behaviour under Devuan.
https://www.mail-archive.com/dng@lists.dyne.org/msg17863.html

if I'm not mistaken.

Interested reader can compare my /etc/skel/.bashrc if they have missing color
in their terminals in Xorg (open the attachment where available)):

_bashrc.gz

However, it might be another bit of code, thanks to which I have color'ed
terminal prompt as regular user... Looking up this diff:

mr@gdOv:~$ diff /etc/skel/.bashrc .bashrc 
40c40
< xterm-color|*-256color) color_prompt=yes;;
---
> xterm-color) color_prompt=yes;;
46c46
< #force_color_prompt=yes
---
> force_color_prompt=yes
113a114,124
[...]

it appears that I set:
force_color_prompt=yes
in my ~/.bashrc . And that actually gives me color'ed mr@gdOv:~$ (I'm not an
expert as I often admit.)

Regards!

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr

_bashrc.gz
Description: application/gzip

signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On Sat, 23 Sep 2017 06:28:30 -0700
Rick Moen  wrote:

> > If the '#' and "root@hostname" escape the attention of a person
> > entrusted with root privileges, then why not make the root prompt bright 
> > red:
> > 
> > root@ratatosk:/home/erik# export PS1="\[\033[1;31m\]\u@\h:\W\$ 
> > \[\033[0;0m\]"  
> 
> It's a very good idea -- or, as Arnt says, set the background colour
> (which you can do with X11 resources if launching root shell directly
> from the window manager).

Do both; that way you get a warning when you log in as root in an X session, 
and also when you log in in a tty.
 
Cheers,
 
Ron.
-- 
   When we remember we are all mad,
  the mysteries disappear and life stands explained.
   -- Mark Twain

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-23 Thread Rick Moen

Quoting Erik Christiansen (dva...@internode.on.net):

> If the '#' and "root@hostname" escape the attention of a person
> entrusted with root privileges, then why not make the root prompt bright red:
> 
> root@ratatosk:/home/erik# export PS1="\[\033[1;31m\]\u@\h:\W\$ \[\033[0;0m\]"

It's a very good idea -- or, as Arnt says, set the background colour
(which you can do with X11 resources if launching root shell directly
from the window manager).

-- 
Rick Moen  "'Decimate' when referring to killing one 
r...@linuxmafia.comin ten.  'Octomate' when referring to the 
McQ!  (4x80)   cephalopod dating site."  -- @FakeAPStylebook
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.


Le 23/09/2017 à 08:49, Alessandro Selli a écrit :

   He's actually right: the least the superuser's password is used, the better
and the safer.


Yep, you can invoke 'sudo su -l'; that's su without the root 
password. It helps you forget the root password.


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.


Le 23/09/2017 à 01:56, Hendrik Boom a écrit :

he problem with su is that you may forget you are superuser and start
doing dangerous things,


Edit the .bashrc of root to have the prompt written in red. That's 
what I always do. Yet it is still dangerous.


You can make exactly the same dangerous things with sudo, by 
definition - and you haven't the red prompt to warn you.


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.


Le 22/09/2017 à 18:51, Hector Gonzalez a écrit :



On 09/22/2017 05:10 AM, Didier Kryn wrote:

Le 22/09/2017 à 01:32, Arnt Karlsen a écrit :

You can probably justify 'xhost +' if this is one of those
I'm-the-only-user machines.  Thank Ghu, remote network access to the X
server is no longer enabled by default on Linux hosts.  (The right way
to do remote X11, IMO, is via 'ssh -yu...@example.com', thereby
forwarding X11 across the authenticated ssh tunnel.)

One can argue that you should use 'ssh -Y' even locally so you get out
of the habit of using 'xhost +'.  I won't argue that, but will just
put it out there.

..my prefecence was the -X option: ssh -X root@localhost
until Debian killed it with some new policy.


AFAIR, ssh -Y is used for backward compatibility with old 
software (like libroot), but, normally, -X is enough.


I don't know how one can prevent you from running ssh -X 
root@localhost . Permission to do so is set/unset in 
/etc/ssh/sshd_config .


But gksu or gksudo do not require ssh at all.


You can also do this, assuming your original user is "user":
XAUTHORITY=~user/.Xauthority
export XAUTHORITY
DISPLAY=:0.0
export DISPLAY
and use x with that.  You don't add permissions, and there is no need 
to use ssh to forward localhost connections.  If XAUTHORITY is 
missing, you need xauth installed, but that should already be there if 
you have ssh and X anyway.  root should have permission to read 
~user/.Xauthority unless you are using a non local home directory.


That's a much nicer solution than openning a window to ask the 
password. Just a question: do su and sudo transmit these environment 
variables? I bet for sudo, it is configurable.


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-23 Thread Erik Christiansen

On 23.09.17 10:15, Arnt Karlsen wrote:
> ..I still miss and prefer the S.u.S.E.-5.2 way, root had a 
> nice red background color in xterms, fairly hard to miss.

If the '#' and "root@hostname" escape the attention of a person
entrusted with root privileges, then why not make the root prompt bright red:

root@ratatosk:/home/erik# export PS1="\[\033[1;31m\]\u@\h:\W\$ \[\033[0;0m\]"

OK, that reverted the '#' to '$', presumably because I'd su-ed, rather
than logged in as root. (\$ => '#' for uid==0, else '$')

As all my xterms are yellow on darkslategrey, one bright red prompt
cannot be missed, even from the other side of the room.

Erik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On Fri, 22 Sep 2017 23:35:37 -0700
Rick Moen  wrote:

> What a pity there isn't a visual indicator that you are weilding root
> authority like, I don't know, maybe the bash shell prompt ending
> character changing from "$" to "#".
> 
> It could work.  Somebody should try it, some time.

I run xfce-console with five tabs open; two logged-in as user, the sprompts are 
black; one logged in as root, the prompt is red; two others logged in as root 
on remote boxes, their prompts are green and blue.

It is simple enough to change PS1='\n\[\033[1;34m\]\u@\h:\w \$ \[\033[0m\]' in 
the various .ashrc to the colour you want/need.

Been using that for years, never had a problem. 

Cheers,

Ron.
-- 
A real patriot is the fellow who gets a parking ticket
 and rejoices that the system works.

   -- http://www.olgiati-in-paraguay.org --

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

Le 22/09/2017 à 13:30, Arnt Karlsen a écrit :

On Fri, 22 Sep 2017 13:03:07 +0200, Arnt wrote in message
<20170922130307.25f57...@nb6.lan>:

On Thu, 21 Sep 2017 16:44:47 -0700, Rick wrote in message
<20170921234447.gp11...@linuxmafia.com>:

Quoting Arnt Karlsen (a...@iaksess.no):

..my prefecence was the -X option: ssh -X root@localhost
until Debian killed it with some new policy.

Was it Debian that did that? I was never sure. I just remember
that 'ssh -X' suddenly no longer did X11 forwarding as it used to,
but I looked up the problem and saw that 'ssh -Y' now did that. I
never chased down the matter further.

..hum, agreed, one of us should have.

(/me Web-searches:)

It has something to do with 'untrusted X11', mentioned in passing
here:
https://unix.stackexchange.com/questions/12755/how-to-forward-x-over-ssh-to-run-graphics-applications-remotely

-Y 'enables trusted X11 forwarding':

https://serverfault.com/questions/273847/what-does-warning-untrusted-x11-forwarding-setup-failed-xauth-key-data-not-ge

"Untrusted" in this context means you don't trust the connection.
SSH will use additional security measures to try to make X11
forwarding safer. "Trusted" means you are entirely confident that no
on on the remote host will get access to your Xauth data and use it
to monitor your keystrokes for instance.

This terminology actually confused me for years. I thought
"Trusted" connections were safer. But actually it's an option
you're supposed to use in situations where the connection IS
trustworthy and you want to run stuff without extra security
measures getting in your way. "Untrusted" is the one that makes it
(somewhat) safer to deal with an untrusted remote host.

An "Untrusted" connection attempts to limit what a black hat could
do to you by engaging the X11 security extension and disabling other
extensions that you (hopefully) don't need. This is probably why
RandR is disabled with -X. Do you need to be able to rotate your X
display from the remote host?

..not really, I would possibly "need" gradual rotations controlled
by an head tracker for use in FlightGear or flying fpv with one of
these:

..http://headplay.com/ , which should have been appended to the
above colon.

..weird net "outage", I had dns, icmp and _nothing_ else,
outside my isp's net.

It's also important to note that "untrusted" X11 forwarding turns
off after a certain amount of time to keep you from accidentally
leaving it on. New attempts to open windows will just fail after
that. That bit me several times before I read enough docs to
understand what was happening.

..if you use passwd-free ssh authorisation, it's simply another
[arrow-up] hit and you're back in.

My surmise is, not a Debian change, so much as a Portable OpenSSH
change.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

As far as I (vaguely) understand it, the allowed X transactions
between the host and the client are restricted to a "secure" subset with
-X, with respect to -Y. And this is why -Y should only used when both
sides are trusted. Maybe they have discovered that that secure subset
isn't secure enough. Anyway this has always been adjustable in
sshd_config and ssh_config, both in general and per address range.

Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.


Le 22/09/2017 à 12:31, Renaud (Ron) OLGIATI a écrit :

On Fri, 22 Sep 2017 12:19:51 +0200
Didier Kryn  wrote:


  However, for at least a decade, the launcher of Synaptic, in
Debian, has been invoking gksu. Certainly some other sysadmin commands
were using it also, but synaptic is the one I mostly use.

When you launch it from the GUI, maybe, but not when launched from the CLI.
Sure. But for me it has never worked after just su, nor with sudo. 
I'm sure you need to do some tricks to achieve that. It doesn't work out 
of the box, or maybe when you are the user who did the install and the 
installer has tricked Policykit to allow you that? Anyway Policykit is 
yet another thing I dislike.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-23 Thread Simon Hobson

Arnt Karlsen  wrote:

>> What a pity there isn't a visual indicator that you are weilding root
>> authority like, I don't know, maybe the bash shell prompt ending
>> character changing from "$" to "#".
>> 
>> It could work.  Somebody should try it, some time.

:D

> ..I still miss and prefer the S.u.S.E.-5.2 way, root had a 
> nice red background color in xterms, fairly hard to miss.

Back when I adminned a bunch of Macs serving individual services, I set the 
desktop to be a repeating tile of the application icon so it was clear which 
one I was connected to at any time. Many times over the years I suggested to my 
Windows admin colleagues that they should set the desktop to show which server 
it is - and so avoid the "oops I  to the wrong one" incidents 
that happened from time to time - but they never listened.

More recently, I've only really done CLI stuff and then the hostname is right 
there as part of the Bash prompt.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-23 Thread Arnt Karlsen

On Fri, 22 Sep 2017 23:35:37 -0700, Rick wrote in message 
<20170923063536.gx11...@linuxmafia.com>:

> Quoting Hendrik Boom (hend...@topoi.pooq.com):
> 
> > The problem with su is that you may forget you are superuser and
> > start doing dangerous things,
> > 
> > That's it.
> 
> What a pity there isn't a visual indicator that you are weilding root
> authority like, I don't know, maybe the bash shell prompt ending
> character changing from "$" to "#".
> 
> It could work.  Somebody should try it, some time.

..I still miss and prefer the S.u.S.E.-5.2 way, root had a 
nice red background color in xterms, fairly hard to miss.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-23 Thread Alessandro Selli

On Thu, 21 Sep 2017 at 12:18:54 -0400
"Renaud (Ron) OLGIATI"  wrote:

> On Thu, 21 Sep 2017 16:33:23 +0100
> KatolaZ  wrote:
>
>> you probably just need to `xhost +` from the "regular" user account
>> before su-ing. By default the current display is not accessible by any
>> user except the one who launched it. root is not an exception.  
>
> Anything against having `xhost +` in ~/.bashrc ?

  Yes, it leaves your barn doors open to everyone.

  If you do not want to use ssh, that is your local network is a secure one,
you could do this:

1) extract your X11 cookie from your local Xorg session:
   [user_a@wrkstn05 ~]$ xauth list $DISPLAY
   wrkstn05/unix:0  MIT-MAGIC-COOKIE-1  120d5357706960bcd453de4886412267

2) merge it into your remote workstations's list of available X11 cookies:
   [user_b@wrkstn03 ~]$ export DISPLAY=wrkstn05:0
   [user_b@wrkstn03 ~]$ xauth add $DISPLAY . 120d5357706960bcd453de4886412267

  The dot "." in the later command is a short notation for MIT-MAGIC-COOKIE-1.

  Now, on the remote machine (wrkstn03) only the user who run the last command
to merge your X11 cookie to his list of usable ones (user_b) can export
windows to your Xorg session, all other users on the same machine
cannot.  Remember however that all data is shuffled between the two machines
over the unsafe, unencrypted X11 protocol.

  Welcome back to the '80s!

Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-23 Thread Edward Bartolo

Quote: "He's actually right: the least the superuser's password is
used, the better
and the safer."

Granted, but sudo as configured in Ubuntu makes the use of a superuser
password pointless. Sudo is configured to be a wide wide open door
leading to any part of a computer's 'household'. In other words, sudo
with the infamous 'user ALL=(ALL)'  in /etc/sudoers makes root
practically like any other user.

Sudo does have its benefits but it must be used to control user
privileges. Granting all commands to every user is the opposite of
what security means.


-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
If you cannot make abstructions about details you do not understand
the concepts underlying them.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-23 Thread Alessandro Selli

On Fri, 22 Sep 2017 at 19:56:27 -0400
Hendrik Boom  wrote:

> On Fri, Sep 22, 2017 at 06:27:59AM +0100, KatolaZ wrote:
>> On Thu, Sep 21, 2017 at 09:41:08PM +0100, Dave Turner wrote:
>>
>> [cut]
>>  
>>> The bottle of wine isn't quite finished yet, but I am not trying to
>>> force anyone to stop using 'su'.
>>> 
>>> It IS a really bad idea though, rummage the interweb, somewhere in
>>> there is a really good write up on why su is bad and sudo is good.  
>
> The problem with su is that you may forget you are superuser and start 
> doing dangerous things,
>
> That's it.

  There's more to that.
  One of the major dangers is that typing passwords is itself dangerous,
expecially in the many environments where webcams and microphones are
abundant.  Both seeing a person type a prassword and recording the sounds
the keyboard produces can easily lead an attacker to reconstruct the password
that was typed.

[...]

> Can we agree there's a valid use for su?

  A few of the times, never when not in a controlled, safe environment.

>  And that is isn't for everyone?

  Indeed.

  Regards,

Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-23 Thread Alessandro Selli

On Thu, 21 Sep 2017 at 20:12:40 +0100
Rowland Penny  wrote:

> On Thu, 21 Sep 2017 19:43:54 +0100
> Dave Turner  wrote:
>
>> 
>> Also, 'su' is just wrong, don't use it, always use sudo, and if you
>> can find a decent .deb of OpenBSD 'doas' ported to linux use that, it
>> is even better!
>>   
>
> Just because you think using 'su' is wrong, doesn't make it wrong, it
> is just wrong for you.

  He's actually right: the least the superuser's password is used, the better
and the safer.

> This is all down to the sysadmins decision and I thought one of the
> main ideas behind Devuan is that nothing is forced on the sysadmin.

  Nowhere did I read Dave trying to take away people's freedom.
Security is important in it's own right, it's not something that takes away
people's freedom.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-23 Thread Rick Moen

Quoting Hendrik Boom (hend...@topoi.pooq.com):

> The problem with su is that you may forget you are superuser and start 
> doing dangerous things,
> 
> That's it.

What a pity there isn't a visual indicator that you are weilding root
authority like, I don't know, maybe the bash shell prompt ending
character changing from "$" to "#".

It could work.  Somebody should try it, some time.

> Can we agree there's a valid use for su?  And that is isn't for 
> everyone?

I'm sorry, you're in the Argument Clinic.  ;->

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-22 Thread Hendrik Boom

On Thu, Sep 21, 2017 at 04:44:47PM -0700, Rick Moen wrote:
> 
>   This terminology actually confused me for years. I thought "Trusted"
>   connections were safer. But actually it's an option you're supposed to
>   use in situations where the connection IS trustworthy and you want to
>   run stuff without extra security measures getting in your way.
>   "Untrusted" is the one that makes it (somewhat) safer to deal with an
>   untrusted remote host.

A "trusted" system is one which, if it were to fail, will screw you utterly.

Ideally, you only trust systems which are trustworthy, whiich is not 
the same thing. 

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-22 Thread Hendrik Boom

On Fri, Sep 22, 2017 at 06:27:59AM +0100, KatolaZ wrote:
> On Thu, Sep 21, 2017 at 09:41:08PM +0100, Dave Turner wrote:
> 
> [cut]
> 
> > The bottle of wine isn't quite finished yet, but I am not trying to force
> > anyone to stop using 'su'.
> > 
> > It IS a really bad idea though, rummage the interweb, somewhere in there is
> > a really good write up on why su is bad and sudo is good.

The problem with su is that you may forget you are superuser and start 
doing dangerous things,

That's it.

If one is good at being careful, and there's enough environmental 
context to remind you you're not an ordinary user, that shouldn't be a 
problem.

I run admin tasks in a shell in virtual console 1.

I run my user tasks in a shell terminal in X.

No confusion arises, and it's convenient to do sysadmin tasks without 
asking "may I" all the time.

Can we agree there's a valid use for su?  And that is isn't for 
everyone?

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-22 Thread Renaud (Ron) OLGIATI

On Fri, 22 Sep 2017 11:51:53 -0500
Hector Gonzalez  wrote:

> You can also do this, assuming your original user is "user":
> XAUTHORITY=~user/.Xauthority
> export XAUTHORITY
> DISPLAY=:0.0
> export DISPLAY
> and use x with that.  You don't add permissions, and there is no need to 
> use ssh to forward localhost connections.  If XAUTHORITY is missing, you 
> need xauth installed, but that should already be there if you have ssh 
> and X anyway.  root should have permission to read ~user/.Xauthority 
> unless you are using a non local home directory.

OTOH, having done nothing to configure ssh, I have ssh -X working perfectly, 
allowing me to run on my desktop a pcmanfm to manage files on the remote box.
 
Cheers,
 
Ron.
-- 
   One way to make your old car run better
   is to look up the price of a new model.

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] New behaviour under Devuan.

2017-09-22 Thread Edward Bartolo

Under Devuan ASCII I have no problem running gparted from a terminal
after becoming root with su. Obviously, the xorg must be running
before attempting to run gparted.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On Fri, 22 Sep 2017 08:54:30 -0400, Renaud wrote in message 
<20170922085430.0b228...@ron.cerrocora.org>:

> On Fri, 22 Sep 2017 14:31:44 +0200
> Arnt Karlsen  wrote:
> 
> > >  I don't know how one can prevent you from running ssh -X 
> > > root@localhost . Permission to do so is set/unset
> > > in /etc/ssh/sshd_config .
> > 
> > ..ok, how?
> 
> "X11Forwarding yes" ?

..yep.  I may be missing something stupid here:
arnt@d44:~/heads$ ssh -vX root@127.0.0.1
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.2l  25 May 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/arnt/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/arnt/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/arnt/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/arnt/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/arnt/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/arnt/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/arnt/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/arnt/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
debug1: Remote protocol version 2.0, remote software version
OpenSSH_6.7p1 Debian-5+deb8u3 
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat
0x0400 
debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-64-...@openssh.com none
debug1: kex: client->server aes128-ctr umac-64-...@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
12:04:9e:f4:23:9b:a6:f7:8c:b1:98:72:cd:13:f2:66 
debug1: Host '127.0.0.1' is known and matches the ECDSA host key. 
debug1: Found key in /home/arnt/.ssh/known_hosts:29 
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/arnt/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/arnt/.ssh/id_dsa
debug1: Trying private key: /home/arnt/.ssh/id_ecdsa
debug1: Trying private key: /home/arnt/.ssh/id_ed25519
debug1: Next authentication method: password
root@127.0.0.1's password: 
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
root@127.0.0.1's password: 

arnt@d44:~/heads$ 

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-22 Thread Rick Moen

Quoting Hector Gonzalez (ca...@genac.org):

> You can also do this, assuming your original user is "user":
> XAUTHORITY=~user/.Xauthority
> export XAUTHORITY
> DISPLAY=:0.0
> export DISPLAY
> and use x with that. 

Some of us like to do 'ssh -Y root@localhost' because we got tired of
messing around with MIT magic cookies and the DISPLAY variable.  ;->

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-22 Thread Hector Gonzalez




On 09/22/2017 05:10 AM, Didier Kryn wrote:

Le 22/09/2017 à 01:32, Arnt Karlsen a écrit :

You can probably justify 'xhost +' if this is one of those
I'm-the-only-user machines.  Thank Ghu, remote network access to the X
server is no longer enabled by default on Linux hosts.  (The right way
to do remote X11, IMO, is via 'ssh -yu...@example.com', thereby
forwarding X11 across the authenticated ssh tunnel.)

One can argue that you should use 'ssh -Y' even locally so you get out
of the habit of using 'xhost +'.  I won't argue that, but will just
put it out there.

..my prefecence was the -X option: ssh -X root@localhost
until Debian killed it with some new policy.


AFAIR, ssh -Y is used for backward compatibility with old software 
(like libroot), but, normally, -X is enough.


I don't know how one can prevent you from running ssh -X 
root@localhost . Permission to do so is set/unset in 
/etc/ssh/sshd_config .


But gksu or gksudo do not require ssh at all.


You can also do this, assuming your original user is "user":
XAUTHORITY=~user/.Xauthority
export XAUTHORITY
DISPLAY=:0.0
export DISPLAY
and use x with that.  You don't add permissions, and there is no need to 
use ssh to forward localhost connections.  If XAUTHORITY is missing, you 
need xauth installed, but that should already be there if you have ssh 
and X anyway.  root should have permission to read ~user/.Xauthority 
unless you are using a non local home directory.


--
Héctor González
ca...@genac.org

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On Fri, 22 Sep 2017 12:10:37 +0200, Didier wrote in message 
<9a258483-ff65-96a3-1ded-5bb121586...@in2p3.fr>:

> Le 22/09/2017 à 01:32, Arnt Karlsen a écrit :
> >> The '-Y' option enables X11 forwarding.  (This of course requires
> >> sshd.)
> >>
> >> You can probably justify 'xhost +' if this is one of those
> >> I'm-the-only-user machines.  Thank Ghu, remote network access to
> >> the X server is no longer enabled by default on Linux hosts.  (The
> >> right way to do remote X11, IMO, is via 'ssh -yu...@example.com',
> >> thereby forwarding X11 across the authenticated ssh tunnel.)
> >>
> >> One can argue that you should use 'ssh -Y' even locally so you get
> >> out of the habit of using 'xhost +'.  I won't argue that, but will
> >> just put it out there.
> > ..my prefecence was the -X option: ssh -X root@localhost
> > until Debian killed it with some new policy.
> 
>  AFAIR, ssh -Y is used for backward compatibility with old
> software (like libroot), but, normally, -X is enough.
> 
>  I don't know how one can prevent you from running ssh -X 
> root@localhost . Permission to do so is set/unset
> in /etc/ssh/sshd_config .

..ok, how?

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On Fri, 22 Sep 2017 13:03:07 +0200, Arnt wrote in message 
<20170922130307.25f57...@nb6.lan>:

> On Thu, 21 Sep 2017 16:44:47 -0700, Rick wrote in message 
> <20170921234447.gp11...@linuxmafia.com>:
> 
> > Quoting Arnt Karlsen (a...@iaksess.no):
> > 
> > > ..my prefecence was the -X option: ssh -X root@localhost
> > > until Debian killed it with some new policy.
> > 
> > Was it Debian that did that?  I was never sure.  I just remember
> > that 'ssh -X' suddenly no longer did X11 forwarding as it used to,
> > but I looked up the problem and saw that 'ssh -Y' now did that.  I
> > never chased down the matter further.
> 
> ..hum, agreed, one of us should have.
> 
> > (/me Web-searches:)
> > 
> > It has something to do with 'untrusted X11', mentioned in passing
> > here:
> > https://unix.stackexchange.com/questions/12755/how-to-forward-x-over-ssh-to-run-graphics-applications-remotely
> > 
> > -Y 'enables trusted X11 forwarding':
> > 
> > https://serverfault.com/questions/273847/what-does-warning-untrusted-x11-forwarding-setup-failed-xauth-key-data-not-ge
> > 
> >   "Untrusted" in this context means you don't trust the connection.
> > SSH will use additional security measures to try to make X11
> > forwarding safer. "Trusted" means you are entirely confident that no
> > on on the remote host will get access to your Xauth data and use it
> > to monitor your keystrokes for instance.
> > 
> >   This terminology actually confused me for years. I thought
> > "Trusted" connections were safer. But actually it's an option
> > you're supposed to use in situations where the connection IS
> > trustworthy and you want to run stuff without extra security
> > measures getting in your way. "Untrusted" is the one that makes it
> > (somewhat) safer to deal with an untrusted remote host.
> > 
> >   An "Untrusted" connection attempts to limit what a black hat could
> > do to you by engaging the X11 security extension and disabling other
> >   extensions that you (hopefully) don't need. This is probably why
> > RandR is disabled with -X. Do you need to be able to rotate your X
> > display from the remote host?
> 
> ..not really, I would possibly "need" gradual rotations controlled 
> by an head tracker for use in FlightGear or flying fpv with one of 
> these: 

..http://headplay.com/ ,  which should have been appended to the 
above colon.

..weird net "outage", I had dns, icmp and _nothing_ else, 
outside my isp's net.

> 
> >   It's also important to note that "untrusted" X11 forwarding turns
> > off after a certain amount of time to keep you from accidentally
> > leaving it on. New attempts to open windows will just fail after
> > that. That bit me several times before I read enough docs to
> > understand what was happening.
> 
> ..if you use passwd-free ssh authorisation, it's simply another
> [arrow-up] hit and you're back in.
> 
> > My surmise is, not a Debian change, so much as a Portable OpenSSH
> > change.
> > 
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
> 


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On Thu, 21 Sep 2017 16:44:47 -0700, Rick wrote in message 
<20170921234447.gp11...@linuxmafia.com>:

> Quoting Arnt Karlsen (a...@iaksess.no):
> 
> > ..my prefecence was the -X option: ssh -X root@localhost
> > until Debian killed it with some new policy.
> 
> Was it Debian that did that?  I was never sure.  I just remember that
> 'ssh -X' suddenly no longer did X11 forwarding as it used to, but I
> looked up the problem and saw that 'ssh -Y' now did that.  I never
> chased down the matter further.

..hum, agreed, one of us should have.

> (/me Web-searches:)
> 
> It has something to do with 'untrusted X11', mentioned in passing
> here:
> https://unix.stackexchange.com/questions/12755/how-to-forward-x-over-ssh-to-run-graphics-applications-remotely
> 
> -Y 'enables trusted X11 forwarding':
> 
> https://serverfault.com/questions/273847/what-does-warning-untrusted-x11-forwarding-setup-failed-xauth-key-data-not-ge
> 
>   "Untrusted" in this context means you don't trust the connection.
> SSH will use additional security measures to try to make X11
> forwarding safer. "Trusted" means you are entirely confident that no
> on on the remote host will get access to your Xauth data and use it
> to monitor your keystrokes for instance.
> 
>   This terminology actually confused me for years. I thought "Trusted"
>   connections were safer. But actually it's an option you're supposed
> to use in situations where the connection IS trustworthy and you want
> to run stuff without extra security measures getting in your way.
>   "Untrusted" is the one that makes it (somewhat) safer to deal with
> an untrusted remote host.
> 
>   An "Untrusted" connection attempts to limit what a black hat could
> do to you by engaging the X11 security extension and disabling other
>   extensions that you (hopefully) don't need. This is probably why
> RandR is disabled with -X. Do you need to be able to rotate your X
> display from the remote host?

..not really, I would possibly "need" gradual rotations controlled 
by an head tracker for use in FlightGear or flying fpv with one of 
these: 

>   It's also important to note that "untrusted" X11 forwarding turns
> off after a certain amount of time to keep you from accidentally
> leaving it on. New attempts to open windows will just fail after
> that. That bit me several times before I read enough docs to
> understand what was happening.

..if you use passwd-free ssh authorisation, it's simply another
[arrow-up] hit and you're back in.

> My surmise is, not a Debian change, so much as a Portable OpenSSH
> change.
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-22 Thread Renaud (Ron) OLGIATI

On Fri, 22 Sep 2017 12:19:51 +0200
Didier Kryn  wrote:

>  However, for at least a decade, the launcher of Synaptic, in 
> Debian, has been invoking gksu. Certainly some other sysadmin commands 
> were using it also, but synaptic is the one I mostly use.

When you launch it from the GUI, maybe, but not when launched from the CLI.
 
Cheers,
 
Ron.
-- 
 A nation of sheep will beget a government of wolves.
 -- Edward R. Murrow

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-22 Thread Didier Kryn


Le 22/09/2017 à 11:41, Klaus Ethgen a écrit :

Not true.

That is the job of pam_xauth.so. Just use it as session plugin in pam.


Interesting. Learning everyday, thanks :-)

However, for at least a decade, the launcher of Synaptic, in 
Debian, has been invoking gksu. Certainly some other sysadmin commands 
were using it also, but synaptic is the one I mostly use.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-22 Thread KatolaZ

On Fri, Sep 22, 2017 at 11:37:14AM +0200, Didier Kryn wrote:
> Le 21/09/2017 à 17:12, Renaud (Ron) OLGIATI a écrit :
> >Under Debian, I could su to root in a console, and launch gparted from the 
> >CLI.
> 
> This could never work. su does not transmit the X connection (don't know
> the details). You got to use gksu or gksudo, or some equivalent command.
> With just su you can only use the CLI parted.
> 

Not true. It works.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-22 Thread Didier Kryn


Le 22/09/2017 à 01:32, Arnt Karlsen a écrit :

The '-Y' option enables X11 forwarding.  (This of course requires
sshd.)

You can probably justify 'xhost +' if this is one of those
I'm-the-only-user machines.  Thank Ghu, remote network access to the X
server is no longer enabled by default on Linux hosts.  (The right way
to do remote X11, IMO, is via 'ssh -yu...@example.com', thereby
forwarding X11 across the authenticated ssh tunnel.)

One can argue that you should use 'ssh -Y' even locally so you get out
of the habit of using 'xhost +'.  I won't argue that, but will just
put it out there.

..my prefecence was the -X option: ssh -X root@localhost
until Debian killed it with some new policy.


AFAIR, ssh -Y is used for backward compatibility with old software 
(like libroot), but, normally, -X is enough.


I don't know how one can prevent you from running ssh -X 
root@localhost . Permission to do so is set/unset in /etc/ssh/sshd_config .


But gksu or gksudo do not require ssh at all.

Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-22 Thread Renaud (Ron) OLGIATI

On Fri, 22 Sep 2017 11:37:14 +0200
Didier Kryn  wrote:

> > Under Debian, I could su to root in a console, and launch gparted from the 
> > CLI.  

>  This could never work. su does not transmit the X connection 

I have no idea whether it _could_ work.

But I know it _did_ work. For many years..
 
Cheers,
 
Ron.
-- 
You must realize that the computer has it in for you.
  The irrefutable proof of this is that the computer
 always does what you tell it to do.

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-22 Thread Klaus Ethgen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Am Fr den 22. Sep 2017 um 10:37 schrieb Didier Kryn:
> Le 21/09/2017 à 17:12, Renaud (Ron) OLGIATI a écrit :
> > Under Debian, I could su to root in a console, and launch gparted from the 
> > CLI.
> 
> This could never work. su does not transmit the X connection (don't know
> the details). You got to use gksu or gksudo, or some equivalent command.
> With just su you can only use the CLI parted.

Not true.

That is the job of pam_xauth.so. Just use it as session plugin in pam.

Gruß
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlnE2uUACgkQpnwKsYAZ
9qw4dgv/Y978XvLHhHqxy9AdK0ZwyiuyzVhdAKvrHk0hQN8CkCkczVb8b+TAybQF
kta1iXepIYw2UbRmMWz8C6smySTUP7S84CILGCBsyxlQQgksAlik9VqJQ2sIqfNY
vN6FVrsGwzPGycjqNs8Z4hDJH65iuZk1o1wpWTDmETZGe/S2RJCevof9QREhxYtl
oVymldScvkR1sCeMSt4pRtREtan4eAqErL2CqqR/hmysmRWwhruuYLUjHsJrwqdM
Q7IeDYRJOXJ14/vM13UaGGz2jTOlXTphOoUgyReSc2Tp5X4FLO+oIKpaZnxltWjr
NPB5cA0OQzH2KoCpYZreK4uRadxACSVpWwb2xtYI/iiAOVeHP44zE+JpIdQVCCrv
L2Fr07outRNzoWXrgZUYV3d+GFmcg+9OrrYd0qDJwtRKGr9SjFcjErLq76Pf2VkR
je2Z51U35emJpOU8I/tVUXLjaQ0eZSdhJFPcIIbQHSbUXzlk+15NZkguKRN0hY1P
5IUgDXs/
=v3y6
-END PGP SIGNATURE-
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-22 Thread Didier Kryn


Le 21/09/2017 à 17:12, Renaud (Ron) OLGIATI a écrit :

Under Debian, I could su to root in a console, and launch gparted from the CLI.


This could never work. su does not transmit the X connection (don't 
know the details). You got to use gksu or gksudo, or some equivalent 
command. With just su you can only use the CLI parted.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread KatolaZ

On Thu, Sep 21, 2017 at 09:41:08PM +0100, Dave Turner wrote:

[cut]

> The bottle of wine isn't quite finished yet, but I am not trying to force
> anyone to stop using 'su'.
> 
> It IS a really bad idea though, rummage the interweb, somewhere in there is
> a really good write up on why su is bad and sudo is good.
> 
> And doas is even better.
> 

and sup is even better, IMHO. But it doesn't look like you have added
"IMHO" to that post :)

The fact that someone on the web writes a blogpost saying that this is
better than that does not make a whole truth.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread Rick Moen

Quoting Arnt Karlsen (a...@iaksess.no):

> ..my prefecence was the -X option: ssh -X root@localhost
> until Debian killed it with some new policy.

Was it Debian that did that? I was never sure. I just remember that
'ssh -X' suddenly no longer did X11 forwarding as it used to, but I
looked up the problem and saw that 'ssh -Y' now did that. I never
chased down the matter further.

(/me Web-searches:)

It has something to do with 'untrusted X11', mentioned in passing here:
https://unix.stackexchange.com/questions/12755/how-to-forward-x-over-ssh-to-run-graphics-applications-remotely

-Y 'enables trusted X11 forwarding':

https://serverfault.com/questions/273847/what-does-warning-untrusted-x11-forwarding-setup-failed-xauth-key-data-not-ge

"Untrusted" in this context means you don't trust the connection. SSH
will use additional security measures to try to make X11 forwarding
safer. "Trusted" means you are entirely confident that no on on the
remote host will get access to your Xauth data and use it to monitor
your keystrokes for instance.

This terminology actually confused me for years. I thought "Trusted"
connections were safer. But actually it's an option you're supposed to
use in situations where the connection IS trustworthy and you want to
run stuff without extra security measures getting in your way.
"Untrusted" is the one that makes it (somewhat) safer to deal with an
untrusted remote host.

An "Untrusted" connection attempts to limit what a black hat could do to
you by engaging the X11 security extension and disabling other
extensions that you (hopefully) don't need. This is probably why RandR
is disabled with -X. Do you need to be able to rotate your X display
from the remote host?

It's also important to note that "untrusted" X11 forwarding turns off
after a certain amount of time to keep you from accidentally leaving it
on. New attempts to open windows will just fail after that. That bit me
several times before I read enough docs to understand what was
happening.

My surmise is, not a Debian change, so much as a Portable OpenSSH change.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread Dave Turner


On 21/09/17 21:41, Dave Turner wrote:

On 21/09/17 21:33, Rowland Penny wrote:

On Thu, 21 Sep 2017 21:18:41 +0100
Arnt Gulbrandsen  wrote:


Rowland Penny writes:

This is all down to the sysadmins decision and I thought one of the
main ideas behind Devuan is that nothing is forced on the sysadmin.

Systemd isn't forced on you. LOTS of other things are, starting with
the choice of .deb as package format.

Arnt

Please stop being obtuse, You know very well what I meant. Devuan has
to make some decision for you, but you accept them by accepting
Devuan. What Devuan doesn't force on you are things like, what GUI to
use (or force you to use one), sudo, su or anything like this. More
importantly, it doesn't force systemd on you.

In the post I replied to, Dave was trying to force everybody to NOT use
su, this, in my opinion, is a denial of freedom of choice.

Rowland
  ___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


The bottle of wine isn't quite finished yet, but I am not trying to 
force anyone to stop using 'su'.


It IS a really bad idea though, rummage the interweb, somewhere in 
there is a really good write up on why su is bad and sudo is good.


And doas is even better.

DaveT

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


The bottle of wine is finished.

once you have found devuan.xpm  save it in /usr/share/X11/xdm/pixmaps

edit /etc/x11/xdm

somewhere around line 62 it needs to be this:-

#if PLANES >= 8
xlogin*logoFileName: /usr/share/X11/xdm/pixmaps/devuan.xpm
#else
xlogin*logoFileName: /usr/share/X11/xdm/pixmaps/debianbw.xpm
#endif

sent without the devaun.xpm attachment beacuse with the attachment the message 
is considered too large and needs moderation.
Watch this space - it might come through later!

DaveT

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread Rowland Penny

On Thu, 21 Sep 2017 21:41:49 +0100
Arnt Gulbrandsen  wrote:

> Rowland Penny writes:
> > Please stop being obtuse, You know very well what I meant.
> 
> I do indeed, and I think you're wrong. Devuan has taken a no-systemd 
> decision, that's all. That isn't a promise from anyone to provide 
> alternatives in any other question, or to make alternative packages.
> Not even an implicit promise.

I never asked for any alternatives for anything, I just think that
nobody should force their opinions on anybody, this is what Dave was
trying to do. He thinks that using 'su' is wrong and very nearly demand
that everybody had to stop using it.

I am beginning to think that you, Arnt, could start an argument in an
empty room. 

Rowland
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread Arnt Gulbrandsen


Rowland Penny writes:

Please stop being obtuse, You know very well what I meant.


I do indeed, and I think you're wrong. Devuan has taken a no-systemd 
decision, that's all. That isn't a promise from anyone to provide 
alternatives in any other question, or to make alternative packages. Not 
even an implicit promise.



Devuan has
to make some decision for you, but you accept them by accepting
Devuan.


I accept them, sure.


What Devuan doesn't force on you are things like, what GUI to
use (or force you to use one), sudo, su or anything like this. More
importantly, it doesn't force systemd on you.


As far as I can tell, the decision is "devian policy's is devuan's, except 
ABSOLUTELY NO SYSTEMD".


Arnt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread Dave Turner


On 21/09/17 21:33, Rowland Penny wrote:

On Thu, 21 Sep 2017 21:18:41 +0100
Arnt Gulbrandsen  wrote:


Rowland Penny writes:

This is all down to the sysadmins decision and I thought one of the
main ideas behind Devuan is that nothing is forced on the sysadmin.

Systemd isn't forced on you. LOTS of other things are, starting with
the choice of .deb as package format.

Arnt

Please stop being obtuse, You know very well what I meant. Devuan has
to make some decision for you, but you accept them by accepting
Devuan. What Devuan doesn't force on you are things like, what GUI to
use (or force you to use one), sudo, su or anything like this. More
importantly, it doesn't force systemd on you.

In the post I replied to, Dave was trying to force everybody to NOT use
su, this, in my opinion, is a denial of freedom of choice.

Rowland
  
___

Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


The bottle of wine isn't quite finished yet, but I am not trying to 
force anyone to stop using 'su'.


It IS a really bad idea though, rummage the interweb, somewhere in there 
is a really good write up on why su is bad and sudo is good.


And doas is even better.

DaveT

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread Rowland Penny

On Thu, 21 Sep 2017 21:18:41 +0100
Arnt Gulbrandsen  wrote:

> Rowland Penny writes:
> > This is all down to the sysadmins decision and I thought one of the
> > main ideas behind Devuan is that nothing is forced on the sysadmin.
> 
> Systemd isn't forced on you. LOTS of other things are, starting with
> the choice of .deb as package format.
> 
> Arnt

Please stop being obtuse, You know very well what I meant. Devuan has
to make some decision for you, but you accept them by accepting
Devuan. What Devuan doesn't force on you are things like, what GUI to
use (or force you to use one), sudo, su or anything like this. More
importantly, it doesn't force systemd on you.

In the post I replied to, Dave was trying to force everybody to NOT use
su, this, in my opinion, is a denial of freedom of choice.

Rowland

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread Arnt Gulbrandsen


Rowland Penny writes:

This is all down to the sysadmins decision and I thought one of the
main ideas behind Devuan is that nothing is forced on the sysadmin.


Systemd isn't forced on you. LOTS of other things are, starting with the 
choice of .deb as package format.


Arnt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread Rowland Penny

On Thu, 21 Sep 2017 19:43:54 +0100
Dave Turner  wrote:

> 
> Also, 'su' is just wrong, don't use it, always use sudo, and if you
> can find a decent .deb of OpenBSD 'doas' ported to linux use that, it
> is even better!
> 

Just because you think using 'su' is wrong, doesn't make it wrong, it
is just wrong for you.

This is all down to the sysadmins decision and I thought one of the
main ideas behind Devuan is that nothing is forced on the sysadmin.

Rowland

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread Rick Moen

Quoting Renaud (Ron) OLGIATI (ren...@olgiati-in-paraguay.org):

> Anything against having `xhost +` in ~/.bashrc ?

Local security, disabling of.

One different method:

$ ssh -Y root@localhost
# gparted &
#

The '-Y' option enables X11 forwarding.  (This of course requires sshd.)

You can probably justify 'xhost +' if this is one of those
I'm-the-only-user machines.  Thank Ghu, remote network access to the X
server is no longer enabled by default on Linux hosts.  (The right way
to do remote X11, IMO, is via 'ssh -Y u...@example.com', thereby
forwarding X11 across the authenticated ssh tunnel.)

One can argue that you should use 'ssh -Y' even locally so you get out
of the habit of using 'xhost +'.  I won't argue that, but will just put
it out there.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On Thu, 21 Sep 2017 19:43:54 +0100
Dave Turner  wrote:

> Also, 'su' is just wrong, don't use it, always use sudo, 

If I wanted to always use sudo I would be running *ubuntu...
 
Cheers,
 
Ron.
-- 
   No one can make you feel inferior without your consent.
  -- Eleanor Roosevelt

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread Dave Turner


On 21/09/17 16:41, fsmithred wrote:

On 09/21/2017 11:33 AM, KatolaZ wrote:

On Thu, Sep 21, 2017 at 11:12:19AM -0400, Renaud (Ron) OLGIATI wrote:

Under Debian, I could su to root in a console, and launch gparted from the CLI.

Now, I get:

ron@ron:~/Desktop $ su
Password:
No protocol specified
xmodmap:  unable to open display ':0.0'
No protocol specified
xmodmap:  unable to open display ':0.0'
No protocol specified
xmodmap:  unable to open display ':0.0'
No protocol specified
xmodmap:  unable to open display ':0.0'
No protocol specified
xmodmap:  unable to open display ':0.0'
No protocol specified
xmodmap:  unable to open display ':0.0'

root@ron:/home/ron/Desktop # gparted
No protocol specified

(gpartedbin:4721): Gtk-WARNING **: cannot open display: :0.0

What did I do wrong ?

And by the way, logging in under xdm (?) I had a shock when the Debian name and 
loogo appeared on the login screen...
  

you probably just need to `xhost +` from the "regular" user account
before su-ing. By default the current display is not accessible by any
user except the one who launched it. root is not an exception.

My2Cents

KatolaZ




I do it all the time without ever using xhost. su to root (not 'su -') and
you should be able to launch graphical apps. I use gparted a lot. I assume
that you mean a console/terminal inside an X-session.

BTW, it's pretty easy to change the logo in xdm, and I'll tell you if I
can remember where the file is. That install is gone already.

I didn't figure out how to change the words. Maybe it's another graphic. I
was looking for text. Anyway, check out the .xpm files in /etc/X11/xpm (I
think it's there and not /usr/share).

fsmithred


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


A rummage around the interweb will find the devuan.xpm file you need, 
then a simple edit and job done. I did it on my iMac. Details to follow 
when I've finished my bottle of wine.


Also, 'su' is just wrong, don't use it, always use sudo, and if you can 
find a decent .deb of OpenBSD 'doas' ported to linux use that, it is 
even better!


DaveT

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On Thu, 21 Sep 2017 16:33:23 +0100
KatolaZ  wrote:

> you probably just need to `xhost +` from the "regular" user account
> before su-ing. By default the current display is not accessible by any
> user except the one who launched it. root is not an exception.

Anything against having `xhost +` in ~/.bashrc ?
 
Cheers,
 
Ron.
-- 
  Any stigma, as the old saying is,
 will serve to beat a dogma.
 -- Philip Guedalla

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

On Thu, 21 Sep 2017 10:39:13 -0500
goli...@dyne.org wrote:

> There was an issue opened up about this 9 months ago:
> https://git.devuan.org/devuan-editors/devuan-art/issues/14
> Devuan alternatives were created specifically for xdm but never 
> transferred to the project and repackaged.

OK ta, I'll look for a different one.
 
Cheers,
 
Ron.
-- 
  Any stigma, as the old saying is,
 will serve to beat a dogma.
 -- Philip Guedalla

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread fsmithred

On 09/21/2017 11:33 AM, KatolaZ wrote:
> On Thu, Sep 21, 2017 at 11:12:19AM -0400, Renaud (Ron) OLGIATI wrote:
>> Under Debian, I could su to root in a console, and launch gparted from the 
>> CLI.
>>
>> Now, I get:
>>
>> ron@ron:~/Desktop $ su
>> Password: 
>> No protocol specified
>> xmodmap:  unable to open display ':0.0'
>> No protocol specified
>> xmodmap:  unable to open display ':0.0'
>> No protocol specified
>> xmodmap:  unable to open display ':0.0'
>> No protocol specified
>> xmodmap:  unable to open display ':0.0'
>> No protocol specified
>> xmodmap:  unable to open display ':0.0'
>> No protocol specified
>> xmodmap:  unable to open display ':0.0'
>>
>> root@ron:/home/ron/Desktop # gparted
>> No protocol specified
>>
>> (gpartedbin:4721): Gtk-WARNING **: cannot open display: :0.0
>>
>> What did I do wrong ?
>>
>> And by the way, logging in under xdm (?) I had a shock when the Debian name 
>> and loogo appeared on the login screen...
>>  
> 
> you probably just need to `xhost +` from the "regular" user account
> before su-ing. By default the current display is not accessible by any
> user except the one who launched it. root is not an exception.
> 
> My2Cents
> 
> KatolaZ
> 
> 
> 

I do it all the time without ever using xhost. su to root (not 'su -') and
you should be able to launch graphical apps. I use gparted a lot. I assume
that you mean a console/terminal inside an X-session.

BTW, it's pretty easy to change the logo in xdm, and I'll tell you if I
can remember where the file is. That install is gone already.

I didn't figure out how to change the words. Maybe it's another graphic. I
was looking for text. Anyway, check out the .xpm files in /etc/X11/xpm (I
think it's there and not /usr/share).

fsmithred


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread golinux


On 2017-09-21 10:12, Renaud (Ron) OLGIATI wrote:


And by the way, logging in under xdm (?) I had a shock when the Debian
name and logo appeared on the login screen...

Cheers,

Ron.


Hi Ron,

There was an issue opened up about this 9 months ago:

https://git.devuan.org/devuan-editors/devuan-art/issues/14

Devuan alternatives were created specifically for xdm but never 
transferred to the project and repackaged.


golinux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New behaviour under Devuan.

2017-09-21 Thread KatolaZ

On Thu, Sep 21, 2017 at 11:12:19AM -0400, Renaud (Ron) OLGIATI wrote:
> Under Debian, I could su to root in a console, and launch gparted from the 
> CLI.
> 
> Now, I get:
> 
> ron@ron:~/Desktop $ su
> Password: 
> No protocol specified
> xmodmap:  unable to open display ':0.0'
> No protocol specified
> xmodmap:  unable to open display ':0.0'
> No protocol specified
> xmodmap:  unable to open display ':0.0'
> No protocol specified
> xmodmap:  unable to open display ':0.0'
> No protocol specified
> xmodmap:  unable to open display ':0.0'
> No protocol specified
> xmodmap:  unable to open display ':0.0'
> 
> root@ron:/home/ron/Desktop # gparted
> No protocol specified
> 
> (gpartedbin:4721): Gtk-WARNING **: cannot open display: :0.0
> 
> What did I do wrong ?
> 
> And by the way, logging in under xdm (?) I had a shock when the Debian name 
> and loogo appeared on the login screen...
>  

you probably just need to `xhost +` from the "regular" user account
before su-ing. By default the current display is not accessible by any
user except the one who launched it. root is not an exception.

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] New behaviour under Devuan.