Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #269270 > unrolled thread

Re: How to run automatically a script as soon root login

Started byGreg Wooledge <greg@wooledge.org>
First post2024-05-13 13:30 +0200
Last post2024-05-13 22:10 +0200
Articles 20 on this page of 35 — 11 participants

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: How to run automatically a script as soon root login Greg Wooledge <greg@wooledge.org> - 2024-05-13 13:30 +0200
    Re: How to run automatically a script as soon root login Mario Marietto <marietto2008@gmail.com> - 2024-05-13 13:50 +0200
      Re: How to run automatically a script as soon root login Greg Wooledge <greg@wooledge.org> - 2024-05-13 14:00 +0200
      Re: How to run automatically a script as soon root login Erwan David <erwan@rail.eu.org> - 2024-05-13 14:00 +0200
      Re: How to run automatically a script as soon root login Nicolas George <george@nsup.org> - 2024-05-13 14:10 +0200
        Re: How to run automatically a script as soon root login Stefan Monnier <monnier@iro.umontreal.ca> - 2024-05-13 15:50 +0200
          Re: How to run automatically a script as soon root login Stefan Monnier <monnier@iro.umontreal.ca> - 2024-05-13 16:20 +0200
            Re: How to run automatically a script as soon root login Mario Marietto <marietto2008@gmail.com> - 2024-05-13 17:30 +0200
              Re: How to run automatically a script as soon root login Richmond <dnomhcir@gmx.com> - 2024-05-13 18:50 +0200
      Re: How to run automatically a script as soon root login Stefan Monnier <monnier@iro.umontreal.ca> - 2024-05-13 14:10 +0200
      Re: How to run automatically a script as soon root login Nicolas George <george@nsup.org> - 2024-05-13 14:20 +0200
        Re: How to run automatically a script as soon root login Erwan David <erwan@rail.eu.org> - 2024-05-13 14:50 +0200
          Re: How to run automatically a script as soon root login Richmond <dnomhcir@gmx.com> - 2024-05-13 15:20 +0200
            Re: How to run automatically a script as soon root login Erwan David <erwan@rail.eu.org> - 2024-05-13 15:20 +0200
            Re: How to run automatically a script as soon root login Greg Wooledge <greg@wooledge.org> - 2024-05-13 15:20 +0200
              Re: How to run automatically a script as soon root login <tomas@tuxteam.de> - 2024-05-13 15:30 +0200
                Re: How to run automatically a script as soon root login Mario Marietto <marietto2008@gmail.com> - 2024-05-13 19:10 +0200
        Re: How to run automatically a script as soon root login <tomas@tuxteam.de> - 2024-05-13 14:50 +0200
          Re: How to run automatically a script as soon root login <tomas@tuxteam.de> - 2024-05-13 15:00 +0200
            Re: How to run automatically a script as soon root login Mario Marietto <marietto2008@gmail.com> - 2024-05-13 15:20 +0200
              Re: How to run automatically a script as soon root login Nicolas George <george@nsup.org> - 2024-05-13 15:30 +0200
                Re: How to run automatically a script as soon root login Mario Marietto <marietto2008@gmail.com> - 2024-05-13 16:00 +0200
          Re: How to run automatically a script as soon root login Nicolas George <george@nsup.org> - 2024-05-13 15:00 +0200
          Re: How to run automatically a script as soon root login Nicolas George <george@nsup.org> - 2024-05-13 15:20 +0200
          Re: How to run automatically a script as soon root login Richmond <dnomhcir@gmx.com> - 2024-05-13 15:20 +0200
        Re: How to run automatically a script as soon root login Richmond <dnomhcir@gmx.com> - 2024-05-13 14:50 +0200
          Re: How to run automatically a script as soon root login Dan Ritter <dsr@randomstring.org> - 2024-05-13 15:10 +0200
      Re: How to run automatically a script as soon root login Dan Ritter <dsr@randomstring.org> - 2024-05-13 14:20 +0200
    Re: How to run automatically a script as soon root login Hans <hans.ullrich@loop.de> - 2024-05-13 18:10 +0200
      Re: How to run automatically a script as soon root login <tomas@tuxteam.de> - 2024-05-13 18:40 +0200
        Re: How to run automatically a script as soon root login Richard <rrosner5@gmail.com> - 2024-05-13 19:10 +0200
      Re: How to run automatically a script as soon root login Greg Wooledge <greg@wooledge.org> - 2024-05-13 21:10 +0200
        Re: How to run automatically a script as soon root login Mario Marietto <marietto2008@gmail.com> - 2024-05-13 21:20 +0200
          Re: How to run automatically a script as soon root login David Wright <deblis@lionunicorn.co.uk> - 2024-05-13 22:00 +0200
            Re: How to run automatically a script as soon root login Mario Marietto <marietto2008@gmail.com> - 2024-05-13 22:10 +0200

Page 1 of 2  [1] 2  Next page →


#269270 — Re: How to run automatically a script as soon root login

FromGreg Wooledge <greg@wooledge.org>
Date2024-05-13 13:30 +0200
SubjectRe: How to run automatically a script as soon root login
Message-ID<IDC2t-d3BB-1@gated-at.bofh.it>
On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:
> .profile
> will always be read as soon as the user logs in, no matter how. Through a
> terminal, a GUI, doesn't matter.

That's not correct.  There are many different GUI login setups where
the .profile is never read.

That said, since this thread is specifically about *root* logins, GUI
logins may not be possible.  It depends on which Display Manager and
Desktop Environment are in use.  Many of them explicitly disallow direct
root logins.

So, ultimately it comes down to what the OP actually requires, and
what type of setup they use.  If they only want this thing to happen
when root logs in directly on a console or ssh, then .profile may
indeed be the correct answer.

[toc] | [next] | [standalone]


#269271

FromMario Marietto <marietto2008@gmail.com>
Date2024-05-13 13:50 +0200
Message-ID<IDClP-d3If-9@gated-at.bofh.it>
In reply to#269270

[Multipart message — attachments visible in raw view] — view raw

--> If they only want this thing to happen when root logs in directly on a
console or ssh, then .profile may indeed be the correct answer.

Yes,I don't need to run xorg and a desktop environment,since warp-cli
disconnect and warp-cli connect do not require them.
I wouldn't to login as root automatically,but I've realized that this
command :

echo 1 > /proc/sys/net/ipv4/ip_forward

work only if I'm root. It does not work using sudo. So,in the end I've
chosen to be root instead of a normal user that can use sudo.

On Mon, May 13, 2024 at 1:24 PM Greg Wooledge <greg@wooledge.org> wrote:

> On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:
> > .profile
> > will always be read as soon as the user logs in, no matter how. Through a
> > terminal, a GUI, doesn't matter.
>
> That's not correct.  There are many different GUI login setups where
> the .profile is never read.
>
> That said, since this thread is specifically about *root* logins, GUI
> logins may not be possible.  It depends on which Display Manager and
> Desktop Environment are in use.  Many of them explicitly disallow direct
> root logins.
>
> So, ultimately it comes down to what the OP actually requires, and
> what type of setup they use.  If they only want this thing to happen
> when root logs in directly on a console or ssh, then .profile may
> indeed be the correct answer.
>
>

-- 
Mario.

[toc] | [prev] | [next] | [standalone]


#269272

FromGreg Wooledge <greg@wooledge.org>
Date2024-05-13 14:00 +0200
Message-ID<IDCvv-d3Lq-7@gated-at.bofh.it>
In reply to#269271
On Mon, May 13, 2024 at 01:48:25PM +0200, Mario Marietto wrote:
> I wouldn't to login as root automatically,but I've realized that this
> command :
> 
> echo 1 > /proc/sys/net/ipv4/ip_forward
> 
> work only if I'm root. It does not work using sudo. So,in the end I've
> chosen to be root instead of a normal user that can use sudo.

Aha!  Classic X-Y problem.

To do this with sudo, you can use a shell:

    sudo sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

However, this particular setting can also be done with sysctl:

    sudo sysctl -w net.ipv4.ip_forward=1

Or if you just want the setting to be made permanent, edit the
/etc/sysctl.conf file, find the line that says:

    # Uncomment the next line to enable packet forwarding for IPv4
    #net.ipv4.ip_forward=1

and remove the # sign in front of net.ipv4.ip_forward=1 and then you
will never have to issue your command manually again.

[toc] | [prev] | [next] | [standalone]


#269273

FromErwan David <erwan@rail.eu.org>
Date2024-05-13 14:00 +0200
Message-ID<IDCvv-d3Lq-9@gated-at.bofh.it>
In reply to#269271
Le 13/05/2024 à 13:48, Mario Marietto a écrit :
> --> If they only want this thing to happen when root logs in directly 
> on a console or ssh, then .profile may indeed be the correct answer.
>
> Yes,I don't need to run xorg and a desktop environment,since warp-cli 
> disconnect and warp-cli connect do not require them.
> I wouldn't to login as root automatically,but I've realized that this 
> command :
>
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> work only if I'm root. It does not work using sudo. So,in the end I've 
> chosen to be root instead of a normal user that can use sudo.
>
>

For this it is sufficient to  use /etc/sysctl.conf

You find in the file shipped by debian


# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1

So you just have to uncomment and it will be done at boot time.


(You have the ipv6 equivalent in the same file, if needed)


-- 
Erwan David

[toc] | [prev] | [next] | [standalone]


#269274

FromNicolas George <george@nsup.org>
Date2024-05-13 14:10 +0200
Message-ID<IDCFb-d43X-3@gated-at.bofh.it>
In reply to#269271
Stefan Monnier (12024-05-13):
> > echo 1 > /proc/sys/net/ipv4/ip_forward
> >
> > work only if I'm root. It does not work using sudo.
> This doesn't sound right.  Maybe you should investigate why you're
> seeing this behavior, rather than work around the problem.
> 
> `sudo` *is* root.

No need to “investigate”, the answer is obvious: in

sudo foo > bar

… the > bar comes before the sudo.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]


#269292

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2024-05-13 15:50 +0200
Message-ID<IDEdX-d4PZ-1@gated-at.bofh.it>
In reply to#269274
>> > echo 1 > /proc/sys/net/ipv4/ip_forward
>> This doesn't sound right.  Maybe you should investigate why you're
> No need to “investigate”, the answer is obvious: in

You don't need to, but I definitely think he does. 🙂


        Stefan

[toc] | [prev] | [next] | [standalone]


#269294

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2024-05-13 16:20 +0200
Message-ID<IDEGZ-d5eQ-1@gated-at.bofh.it>
In reply to#269292
> You don't need to, but I definitely think he does. 🙂
                                            ^^

[ Oh, bias, when will you leave me alone?  ]


        Stefan

[toc] | [prev] | [next] | [standalone]


#269295

FromMario Marietto <marietto2008@gmail.com>
Date2024-05-13 17:30 +0200
Message-ID<IDFMJ-d5Qf-1@gated-at.bofh.it>
In reply to#269294

[Multipart message — attachments visible in raw view] — view raw

There is still a problem. If I login automatically as user and inside the
script I do this :

sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE

it asks me for the password (don't know why it didn't before) but I can't
issue a password,because the script inside the vm should work automatically
and should be hidden between the FreeBSD processes.

On Mon, May 13, 2024 at 4:11 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > You don't need to, but I definitely think he does. 🙂
>                                             ^^
>
> [ Oh, bias, when will you leave me alone?  ]
>
>
>         Stefan
>
>

-- 
Mario.

[toc] | [prev] | [next] | [standalone]


#269300

FromRichmond <dnomhcir@gmx.com>
Date2024-05-13 18:50 +0200
Message-ID<IDH29-d6uY-1@gated-at.bofh.it>
In reply to#269295
Mario Marietto <marietto2008@gmail.com> writes:

> There is still a problem. If I login automatically as user and inside
> the script I do this :
>
> sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
>
> it asks me for the password (don't know why it didn't before) but I
> can't issue a password,because the script inside the vm should work
> automatically and should be hidden between the FreeBSD processes.
>

Why does it need to be executed at login? Maybe you could get root's
crontab to execute it. A script could detect when a user is logged in.

[toc] | [prev] | [next] | [standalone]


#269275

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2024-05-13 14:10 +0200
Message-ID<IDCFb-d43X-5@gated-at.bofh.it>
In reply to#269271
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> work only if I'm root. It does not work using sudo.

This doesn't sound right.  Maybe you should investigate why you're
seeing this behavior, rather than work around the problem.

`sudo` *is* root.


        Stefan

[toc] | [prev] | [next] | [standalone]


#269276

FromNicolas George <george@nsup.org>
Date2024-05-13 14:20 +0200
Message-ID<IDCOR-d47e-1@gated-at.bofh.it>
In reply to#269271
Dan Ritter (12024-05-13):
> Mario Marietto wrote:> If you run 
> 
> sudo echo 1 > /proc/sys/net/ipv4/ip_forward
> 
> then the shell you are running it from will run "sudo echo 1"
> and then try to put the output in that file.

Other way around: the shell first tries to redirect the output to the
file and then (if it succeeds) runs sudo that way.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]


#269278

FromErwan David <erwan@rail.eu.org>
Date2024-05-13 14:50 +0200
Message-ID<IDDhT-d4gY-5@gated-at.bofh.it>
In reply to#269276
Le 13/05/2024 à 14:36, Richmond a écrit :
> I was experimenting, and found this works:
>
> sudo xterm -e "echo 1 > hello"
>
> It created a file owned by root. But I found I was able to remove it
> without being root even though group and world permissions were read
> only.
>
>
thats because sudo exceutes a xterm as root

then this xterm executes a shell (as root) and this root shell does the 
redirection.


-- 
Erwan David

[toc] | [prev] | [next] | [standalone]


#269284

FromRichmond <dnomhcir@gmx.com>
Date2024-05-13 15:20 +0200
Message-ID<IDDKW-d4Gq-5@gated-at.bofh.it>
In reply to#269278
Erwan David <erwan@rail.eu.org> writes:

> Le 13/05/2024 à 14:36, Richmond a écrit :
>> I was experimenting, and found this works:
>>
>> sudo xterm -e "echo 1 > hello"
>>
>> It created a file owned by root. But I found I was able to remove it
>> without being root even though group and world permissions were read
>> only.
>>
>>
> thats because sudo exceutes a xterm as root
>
> then this xterm executes a shell (as root) and this root shell does
> the redirection.

Yes, but why did it allow me to delete the file? I was not root
then. Try it.

[toc] | [prev] | [next] | [standalone]


#269286

FromErwan David <erwan@rail.eu.org>
Date2024-05-13 15:20 +0200
Message-ID<IDDKW-d4Gq-7@gated-at.bofh.it>
In reply to#269284
Le 13/05/2024 à 15:03, Richmond a écrit :
> Erwan David <erwan@rail.eu.org> writes:
>
>> Le 13/05/2024 à 14:36, Richmond a écrit :
>>> I was experimenting, and found this works:
>>>
>>> sudo xterm -e "echo 1 > hello"
>>>
>>> It created a file owned by root. But I found I was able to remove it
>>> without being root even though group and world permissions were read
>>> only.
>>>
>>>
>> thats because sudo exceutes a xterm as root
>>
>> then this xterm executes a shell (as root) and this root shell does
>> the redirection.
> Yes, but why did it allow me to delete the file? I was not root
> then. Try it.
>
>
as said Dan Ritter : the owner of the directory can delete any file 
inside the directory.

(see a directory as a special file containing pairs (name,file place on 
the disk). Deleting a file is just removing the pair from the directory, 
thus it is editing the directory, not the file.

-- 
Erwan David

[toc] | [prev] | [next] | [standalone]


#269289

FromGreg Wooledge <greg@wooledge.org>
Date2024-05-13 15:20 +0200
Message-ID<IDDKW-d4Gq-11@gated-at.bofh.it>
In reply to#269284
On Mon, May 13, 2024 at 02:03:59PM +0100, Richmond wrote:
> >> sudo xterm -e "echo 1 > hello"

> Yes, but why did it allow me to delete the file? I was not root
> then. Try it.

Because you have write permission on the *directory* that the file is in.

Removing (unlinking) a file is an operation that modifies a directory,
not the file itself.  You don't need write permission on the file.  Just
the directory.

[toc] | [prev] | [next] | [standalone]


#269291

From<tomas@tuxteam.de>
Date2024-05-13 15:30 +0200
Message-ID<IDDUB-d4Js-5@gated-at.bofh.it>
In reply to#269289

[Multipart message — attachments visible in raw view] — view raw

On Mon, May 13, 2024 at 09:17:31AM -0400, Greg Wooledge wrote:
> On Mon, May 13, 2024 at 02:03:59PM +0100, Richmond wrote:
> > >> sudo xterm -e "echo 1 > hello"
> 
> > Yes, but why did it allow me to delete the file? I was not root
> > then. Try it.
> 
> Because you have write permission on the *directory* that the file is in.
> 
> Removing (unlinking) a file is an operation that modifies a directory,
> not the file itself.  You don't need write permission on the file.  Just
> the directory.

Unless the directory has the sticky bit set (e.g. /tmp).

(For completeness: I know you know that).

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#269302

FromMario Marietto <marietto2008@gmail.com>
Date2024-05-13 19:10 +0200
Message-ID<IDHlx-d6Ra-21@gated-at.bofh.it>
In reply to#269291

[Multipart message — attachments visible in raw view] — view raw

I think I have found my way,adding this line to /etc/sudoers :

marietto ALL=(ALL) NOPASSWD: /usr/bin/iptables

and on the warp script :

sudo /usr/bin/iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE

On Mon, May 13, 2024 at 3:20 PM <tomas@tuxteam.de> wrote:

> On Mon, May 13, 2024 at 09:17:31AM -0400, Greg Wooledge wrote:
> > On Mon, May 13, 2024 at 02:03:59PM +0100, Richmond wrote:
> > > >> sudo xterm -e "echo 1 > hello"
> >
> > > Yes, but why did it allow me to delete the file? I was not root
> > > then. Try it.
> >
> > Because you have write permission on the *directory* that the file is in.
> >
> > Removing (unlinking) a file is an operation that modifies a directory,
> > not the file itself.  You don't need write permission on the file.  Just
> > the directory.
>
> Unless the directory has the sticky bit set (e.g. /tmp).
>
> (For completeness: I know you know that).
>
> Cheers
> --
> t
>


-- 
Mario.

[toc] | [prev] | [next] | [standalone]


#269279

From<tomas@tuxteam.de>
Date2024-05-13 14:50 +0200
Message-ID<IDDhT-d4gY-1@gated-at.bofh.it>
In reply to#269276

[Multipart message — attachments visible in raw view] — view raw

On Mon, May 13, 2024 at 01:36:23PM +0100, Richmond wrote:
> I was experimenting, and found this works:
> 
> sudo xterm -e "echo 1 > hello"

That's like slicing your morning baguette with the chainsaw.

But if it works for you... hey :-)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#269281

From<tomas@tuxteam.de>
Date2024-05-13 15:00 +0200
Message-ID<IDDrz-d4ko-1@gated-at.bofh.it>
In reply to#269279

[Multipart message — attachments visible in raw view] — view raw

On Mon, May 13, 2024 at 02:53:18PM +0200, Nicolas George wrote:
> tomas@tuxteam.de (12024-05-13):
> > That's like slicing your morning baguette with the chainsaw.
> 
> Worse than that, it will only work from an X11 environment. Certainly
> not at boot.

The analogy to that would be that not many kitchens are equipped with
a chainsaw. Mine isn't ;-)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#269287

FromMario Marietto <marietto2008@gmail.com>
Date2024-05-13 15:20 +0200
Message-ID<IDDKW-d4Gq-9@gated-at.bofh.it>
In reply to#269281

[Multipart message — attachments visible in raw view] — view raw

The command iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
doesn't work if invoked as a user,it says "you must be root". So,as
user,the script seems to be working fine like this :

function jumpto
{
        label=$1
        cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
        eval "$cmd"
        exit
}

start=${1:-"start"}

jumpto $start

start:
warp-cli disconnect
OLD_IP="$(curl -s api.ipify.org)"
#echo 1 > /proc/sys/net/ipv4/ip_forward (because I've uncommented this
command inside the file /etc/sysctl.conf)
sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
warp-cli connect
NEW_IP="$(curl -s api.ipify.org)"
echo Connected to Cloudflare Warp...
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP

mid :
if [ "$OLD_IP = $NEW_IP ]
then
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it does not work
anymore,reconnecting...
sleep 10
jump foo
else
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it still works.
sleep 10
fi
jumpto mid

foo:
warp-cli disconnect
OLD_IP="$(curl -s api.ipify.org)"
warp-cli connect
NEW_IP="$(curl -s api.ipify.org)"
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it works again.
jumpto mid

On Mon, May 13, 2024 at 2:59 PM <tomas@tuxteam.de> wrote:

> On Mon, May 13, 2024 at 02:53:18PM +0200, Nicolas George wrote:
> > tomas@tuxteam.de (12024-05-13):
> > > That's like slicing your morning baguette with the chainsaw.
> >
> > Worse than that, it will only work from an X11 environment. Certainly
> > not at boot.
>
> The analogy to that would be that not many kitchens are equipped with
> a chainsaw. Mine isn't ;-)
>
> Cheers
> --
> t
>


-- 
Mario.

[toc] | [prev] | [next] | [standalone]


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user


csiph-web