bl-welcome fails if sudo rights are granted by /etc/suoders.d/ entries

Bearded_Blunder · 2016-09-03 01:49:53

I hate logging in here from freshly reverted snapshots so I can paste stuff, I either have to install lastpass, or copy-type an impossible to remember password, the login timeout is also annoyingly short if I've to compose a longer response.

johnraff wrote:

Yes I'm thinking that the later 'sudo -v' is already doing the necessary test of the user's sudo powers, making the check for the "sudo" group earlier unnecessary.

If it were doing what you expect it to I would completely agree..

johnraff wrote:

Stop right there. @B_B What version of sudo are you using? On my system, 'sudo -v' returns failure if ran by a user without sudo permissions, and 'sudo -l /usr/bin/sudo' returns "/usr/bin/sudo", as 'man sudo' confirms.

With some more details.. I'm running 32 bit, my testbed lacks vt-x so no 64 bit VMs

no-sudo@bl-ad-test:~$ apt-cache policy sudo
sudo:
  Installed: 1.8.10p3-1+deb8u3
  Candidate: 1.8.10p3-1+deb8u3
  Version table:
 *** 1.8.10p3-1+deb8u3 0
        500 http://httpredir.debian.org/debian/ jessie/main i386 Packages
        500 http://security.debian.org/ jessie/updates/main i386 Packages
        100 /var/lib/dpkg/status
no-sudo@bl-ad-test:~$ which sudo
/usr/bin/sudo
no-sudo@bl-ad-test:~$ uname -r
3.16.0-4-686-pae

Bearded_Blunder wrote:

The issue is, that for plain users (no sudo), sudo -v simply returns, no password prompt, and the script continues...

johnraff wrote:

...I find this hard to understand.

As do I, nevertheless... hence tracking down and composing a test that does give the result one expects from sudo -v

johnraff wrote:

If it's not too much trouble, could you try running the script as 'bash -x bl-welcome'?
This will output a lot of irrelevant stuff, but if you could scroll back to the section around the sudo -v command it might show what's wrong.

I did, but since the output was "unuseful", I skipped the pain of logging in from a VM I'd have to copy-type that horrible password to last time I posted, for completeness, having done so again, and come here from that machine:

Please enter your password now and it will be stored for a while.
(You may need to enter it again later.)'
+++ tput cols
++ local width=82
++ sed 's/^/  /'
++ fold -s -w 79
  
  Please enter your password now and it will be stored for a while.
  (You may need to enter it again later.)
++ [[ '' = \p\a\u\s\e ]]
++ sleep 0
++ sudo -v
++ say 'Thank you.'
+++ tput cols
++ local width=82
++ fold -s -w 79
++ sed 's/^/  /'
  Thank you.
++ [[ '' = \p\a\u\s\e ]]
++ sleep 0
+ (( STEP++ ))
+ . /usr/lib/bunsen/welcome/warning
++ WARNING_TITLE='A Warning'
++ WARNING_TEXT='While FOSS is primarily about freedom and choice, certain choices are
known to carry an increased risk of breaking things in BunsenLabs.

Two of the riskier things are:
 * adding Ubuntu PPAs or unknown/untrusted repos to your
   /etc/apt/sources.list or /etc/apt/sources.list.d
 * installing a package that wants a newer version of libc6

More information on some of the riskier things, the above included,
can be found here:
https://wiki.debian.org/DontBreakDebian

(Right click the above link and choose "Open Link" to visit the page.)

Please type "I understand" to continue with this script.

'
++ WARNING_PROMPT='  Enter "I understand" to continue. (Q to quit) '
++ WARNING_EXTRA_ARG='I understand'
++ setupPage 'A Warning' 'While FOSS is primarily about freedom and choice, certain choices are
known to carry an increased risk of breaking things in BunsenLabs.

Two of the riskier things are:
 * adding Ubuntu PPAs or unknown/untrusted repos to your
   /etc/apt/sources.list or /etc/apt/sources.list.d
 * installing a package that wants a newer version of libc6

More information on some of the riskier things, the above included,
can be found here:
https://wiki.debian.org/DontBreakDebian

(Right click the above link and choose "Open Link" to visit the page.)

Please type "I understand" to continue with this script

As you see, it executed, treating it as a passed test.... This is from a base install, where I ran the script as the first user, accepting all the defaults, so it's up to date, I subsequently did the following:
Added a local non sudo user:

sudo adduser --add_extra_groups no-sudo

Commented out the groups test, logged out, and logged in as no-sudo, quit bl-welcome when it popped up, you see part of the output above from running bash -x bl-welcome.
I now have to reinstall realmd sssd and rejoin the domain.. as I went right back to square 1.

johnraff wrote:

Why 'sudo -v' does not work as a check for B_B remains mysterious.

Agreed, but it doesn't.

C & P of some interactions in a terminal for your perusal, having once again reverted my snapshot, re-added the user, and logged in on no-sudo's account, quit bl-welcome right away, and started the below.
Note that sudo -v at the start just came right back:

no-sudo@bl-ad-test:~$ sudo -v
no-sudo@bl-ad-test:~$ sudo -l /usr/bin/sudo

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for no-sudo: 
no-sudo@bl-ad-test:~$ su beardy
Password: 
beardy@bl-ad-test:/home/no-sudo$ sudo -v
[sudo] password for beardy: 
beardy@bl-ad-test:/home/no-sudo$ sudo -k
beardy@bl-ad-test:/home/no-sudo$ sudo -l /usr/bin/sudo
[sudo] password for beardy: 
/usr/bin/sudo
beardy@bl-ad-test:/home/no-sudo$ su no-sudo
Password: 
no-sudo@bl-ad-test:~$

I don't know why sudo -v isn't working either, maybe it's a bug in the 32 bit version, who knows? However, sudo -l /usr/bin/sudo does work for a test, hence me suggesting you substitute

if [[ $(sudo -l /usr/bin/sudo | grep /usr/bin/sudo) ]]

for

if sudo -v

in the script.

johnraff · 2016-09-05 03:06:41

Sorry, but your test results are not consistent with mine.

There seems to be something strange about the way your system is set up.

On a 32bit system, a user tester created by 'adduser username':

tester@bunsen:~$ sudo -v
Sorry, user tester may not run sudo on bunsen.
tester@bunsen:~$ echo $?
1

I have just duplicated this result on my regular 64bit system on tty4, this time using your '--add_extra_groups' option, which makes no difference of course.

The large block of code you posted above suggests that for some reason no-sudo has sudo privileges, in fact.

sudo -l does not reject the non-sudo user till after the password has been entered, while sudo -v catches it immediately and exits with a message. I see no reason to replace sudo -v till an explanation can be found for why it might not work for some users.

Can anyone else duplicate Bearded_Blunder's problems with sudo -v ?

Bearded_Blunder · 2016-09-05 13:04:31

johnraff wrote:

Why 'sudo -v' does not work as a check for B_B remains mysterious.

FOUND IT!

I now have to proffer sincere apologies for some wasted time.

"B_B earlier wrote:

This is from a base install

I only thought it was, I'd evidently reverted to the wrong snapshot, having decided to check if it was a function of running under VmWare EXSi, I created a VM using VirtualBox and step by step worked through building up an AD joined system, apt-getting each item individually, rather than en-bloc, and testing sudo -v after each change, no matter how trivial.

The rogue is

sudo apt-get install sssd

as soon as I did that:

nosudo@sudo-test-vbox:~$ sudo -v
nosudo@sudo-test-vbox:~$ echo $?
0
nosudo@sudo-test-vbox:~$

I suppose a possible workaround would be to check

dpkg -l | grep "ii  sssd"

and pick test for sudo accordingly?

Last edited by Bearded_Blunder (2016-09-05 13:14:13)

johnraff · 2016-09-06 05:16:12

That's good news! I was beginning to wonder if I was missing something glaringly obvious...

sssd does seem to affect the way sudo works, but it might be possible to get things back into shape with some configuration:
https://fedorahosted.org/sssd/wiki/HOWT … shoot_SUDO
http://linux.die.net/man/5/sssd-sudo

I think it would probably be better from your point of view to get sudo behaving "normally" than to hack bl-welcome to deal with the idiosyncracies introduced by sssd.

Bearded_Blunder · 2016-09-06 10:15:50

Indeed, *if I can* a rather biggish if, I'm no guru just a relative Linux n00b and *adequate* Windows admin, and that documentation is for versions which are umpteen steps newer than what's in Jessie, somewhat impenetrable, and links to possibly related bugs fixed in versions not even available in experimental so trying back-porting newer versions from the repos isn't an option, there's also a possibly related sudo bug, targeted for fix in sudo 1.8.18, which ain't even out yet.
I may end up hacking bl-welcome locally instead, though I'd prefer to avoid that owing to the administrative overhead when it gets updated.

#21 2016-09-03 01:49:53

Re: bl-welcome fails if sudo rights are granted by /etc/suoders.d/ entries

#22 2016-09-05 03:06:41

Re: bl-welcome fails if sudo rights are granted by /etc/suoders.d/ entries

#23 2016-09-05 13:04:31

Re: bl-welcome fails if sudo rights are granted by /etc/suoders.d/ entries

FOUND IT!

#24 2016-09-06 05:16:12

Re: bl-welcome fails if sudo rights are granted by /etc/suoders.d/ entries

#25 2016-09-06 10:15:50

Re: bl-welcome fails if sudo rights are granted by /etc/suoders.d/ entries

Board footer