lmi
[Top][All Lists]
Advanced

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

Re: [lmi] sudo make root a sandwich


From: Greg Chicares
Subject: Re: [lmi] sudo make root a sandwich
Date: Mon, 18 May 2020 21:48:44 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 2020-05-18 19:01, Vadim Zeitlin wrote:
> On Mon, 18 May 2020 18:32:08 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Vadim--On our corporate RHEL-7 server, we've been doing this:
> GC> 
> GC>   $ cd /opt/lmi/src/lmi
> GC>   $ sudo ./install_redhat.sh > ~/rhlog_$(date -u +'%Y%m%dT%H%MZ') 2>&1
> GC> 
> GC> successfully for months, until today--but now it's failing thus:
> GC> 
> GC>   sudo  --user="${NORMAL_USER}"  ./lmi_setup_30.sh
> GC>   root is not in the sudoers file.  This incident will be reported.
> 
>  Note that this is just a stock sudo error message, it doesn't actually
> mean that it's going to be reported anywhere and IME in most cases it isn't
> because nobody bothered setting up sudo to do it. But it still might, of
> course.

Sed quis custodiet ipsos custodes?
  sed -i /var/spool/mail/root -e"s/$(logname)/\a\a\a\a\f\a\a\a\a/g"
But actually it doesn't matter much, because the message resulting
from my activity today says:
  my_id : user NOT in sudoers ; TTY=pts/0 ; PWD=/opt/lmi/src/lmi ; \
  USER = my_id ; COMMAND=./lmi_setup_30.sh
which seems to make no sense, because my_id *is* in sudoers,
so it's like being cited for driving at the exact speed limit
while in possession of a current driving license.

> GC> I suppose this is just a silly mistake, but corporate mistakes
> GC> cannot be fixed.
> 
>  Could they perhaps be reported to at least ask whether it is a mistake or
> not? Because if it isn't a mistake, it seems quite likely that they're
> going to remove the ability to use "su" too next, because it just doesn't
> make sense to forbid sudo while allowing su.

Quid sit futurum cras, fuge quaerere, et quem fors dierum cumque
dabit, lucro appone.

> GC> I might just replace the offending line to run the sub-script
> GC> with excessive privileges:
> GC> 
> GC> - sudo  --user="${NORMAL_USER}"  ./lmi_setup_30.sh
> GC> +                                ./lmi_setup_30.sh
> GC> 
> GC> because that's expedient; but is there a "proper" workaround?
> 
>  Sorry if I'm forgetting something, but can't you just use "su" instead? I
> remember that you couldn't create new users on this machine, but are you
> also prevented from su'ing to the existing ones?

Wow, thanks, that actually worked.

$whoami
my_id
$sudo su
#whoami
root
#su my_id -c whoami
my_id
#su someone_elses_id -c whoami
someone_elses_id
#whoami
root
#exit
$whoami
my_id

I'm surprised, because previously I had tried impersonating
someone_else using 'sudo --user=someone_else', and that failed.
Perhaps this means I can test the multi-user-ness of the
chroot on this server.

> GC> 'doas' has apparently been ported from BSD, but it doesn't
> GC> seem to be in RHEL.
> 
>  You could always compile it from source (and when you will be forbidden to
> use the compiler, you could still compile it on another system and enter
> hexadecimal bytes using shell escapes...)

That sounds like a job for cpio.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]