How to allow execution of a script requiring root privileges?

[Bengt T]

In my backup script, using rsync, some directories/files will not be processed because they are only accessible by root. My way around this is to use "sudo my_backup.script" and provide a password.

My wish is to allow execution of the backup script directly without "sudo..." and password.

Is/are there any way/s to accomplish this?

[Carlos E.R.]

Yes... making the script suid or sgid.

However, that poses a security danger.


--
Cheers, Carlos.

[Aragorn]

On 08.04.2020 at 19:20, Carlos E.R. scribbled:

Not really, because the Linux kernel ignores SUID/SGID on scripts. ;)


--
With respect,
= Aragorn =

[Aragorn]

On 08.04.2020 at 19:54, Aragorn scribbled:

A better solution would be to set up /etc/sudoers so that the script
may be executed passwordlessly — if that's not a word, then it is now
:p — and perhaps create an alias or a shell function to invoke the
script with the "sudo" prefix. ;)

[Ned Latham]

Put your username and rsync in /etc/sudoers

[J.O. Aho]

That would be a security issue, as now you allow the user to sync any
file, in which ever direction, so with all the vulnerabilities in
browsers in theory a remote attacker could overwrite or create new files
in where ever on the system.

It's far safer to allow the user to execute the script in /etc/sudoers.
Sure a remote attacker could execute the script in the same manner as in
the example before, but they would have a lot less control of what they
can do, this case it would be just filling the hard drive with new
backups, which is kind of harmless compared to compromise a system.


--

//Aho

[Carlos E.R.]

On 08/04/2020 20.13, J.O. Aho wrote:
> On 08/04/2020 20.00, Ned Latham wrote:
>> Bengt T wrote:
>>>
>>> In my backup script, using rsync, some directories/files will not be
>>> processed because they are only accessible by root. My way around this
>>> is to use "sudo my_backup.script" and provide a password.
>>>
>>> My wish is to allow execution of the backup script directly without
>>> "sudo..." and password.
>>>
>>> Is/are there any way/s to accomplish this?
>>
>> Put your username and rsync in /etc/sudoers
>  That would be a security issue, as now you allow the user to sync any
> file, in which ever direction, so with all the vulnerabilities in
> browsers in theory a remote attacker could overwrite or create new files
> in where ever on the system.

Then put the exact rsync concoction in sudoers :-)



--
Cheers, Carlos.

[Bengt T]

>
> Put your username and rsync in /etc/sudoers

As I understand the following should be added into /etc/sudoers file:

<my_user_name> ALL= /usr/bin/rsync

Is this correct?

[Soviet_Mario]

could you delve deeper into this ....
I can't understand the relation between a given script and
sudoers


--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[Aragorn]

On 08.04.2020 at 21:30, Soviet_Mario scribbled:

> On 08/04/20 19:58, Aragorn wrote:
> > On 08.04.2020 at 19:54, Aragorn scribbled:
> >
> >> On 08.04.2020 at 19:20, Carlos E.R. scribbled:
> >>
> >>> On 08/04/2020 19.02, Bengt T wrote:
> >>>> In my backup script, using rsync, some directories/files will not
> >>>> be processed because they are only accessible by root. My way
> >>>> around this is to use "sudo my_backup.script" and provide a
> >>>> password.
> >>>>
> >>>> My wish is to allow execution of the backup script directly
> >>>> without "sudo..." and password.
> >>>>
> >>>> Is/are there any way/s to accomplish this?
> >>>
> >>> Yes... making the script suid or sgid.
> >>>
> >>> However, that poses a security danger.
> >>
> >> Not really, because the Linux kernel ignores SUID/SGID on scripts.
> >> ;)
> >
> > A better solution would be to set up /etc/sudoers so that the script
> > may be executed passwordlessly — if that's not a word, then it is
> > now :p — and perhaps create an alias or a shell function to invoke
> > the script with the "sudo" prefix. ;)
> >
> >
>
> could you delve deeper into this ....
> I can't understand the relation between a given script and
> sudoers

You can set the permissions in /etc/sudoers [*] so that a certain user
can execute certain commands with root privileges without requiring a
password. A script is a command too. :)


[*] Read The /Fine/ Manual. :p

[F Russell]

On Wed, 08 Apr 2020 10:02:47 -0700, Bengt T wrote:

> In my backup script, using rsync, some directories/files will not be processed
> because they are only accessible by root. My way around this is to use "sudo
>

Your "way around" should be to boot up as the root user and
stay as the root user.

For the single-user workstation this is the ONLY way.

I still hear moans and groans about running as root but
all of that security nonsense is just that: nonsense.
They can always spout off with generalities but they
can never provide specific examples about how a single-user
workstation can be compromised by running as root.

[mGhost]

Sure, the idea is that someone might craft a link which floods a buffer
in such a way that the code they want to execute is sitting somewhere in
memory where there exploit executes it. Without a privileged account,
that execution would fail. With a root level user running, it executes
and opens Pandora's box.

You don't want to be the unknowing victim of some clever attacks where
by you make their job even easier. It doesn't take much to open a port
on your machine, to a command and control service if your own system
doesn't even stop ask you if it should, which it won't if you're already
root and as root, you interact with their exploit.

What if I write a simple script, which looks normal to you, but the
script loads more instructions from the web, which you don't see. It's
not in the script you see, except for loading of it. You run it, and as
root, I tell your system download an execute a cron job headlessly. And
every 10 minutes you're machine asks my machine what I want it to do on
my behalf. Not too fun. I could setup accounts, take screen shots, raid
your files and upload them to me, grab you email, decrypt your encrypted
files, encrypt your drive, and do pretty much anything I want. I'm root.

--
Я гость в отеле

[Wildman]

Would not the person writting the script haved to be a
complete idiot? You create a script that opens a port
on the internet without you knowing it? Nonsense.

--
<Wildman> GNU/Linux user #557453
"Gun control requires concentration and a steady hand."
-John Wayne

[F Russell]

On Wed, 08 Apr 2020 21:47:28 +0000, mGhost wrote:

> It doesn't take much to open a port
> on your machine, to a command and control service
>

Service? I have no service(s) running on my machine.

For what do I need a service? If something needs to
be done I do it myself.

So your whole idea of exploitation is a pipe dream
and could never happen.

Unix was created way back when no one had computers
and hence they had concepts of multi-users and
services..

But in the age of PERSONAL COMPUTERS, those concepts
no longer apply and are extremely anachronistic.

Just always run as root and tell these security idiots
to kiss off.

[mGhost]

Let me be more clear. Say I KNOW you like to run as root all the time.
And one day in conversation you ask for a script that does a certain
thing. So I write it, and send it to you. It does what you asked, and a
little more for me.

Because you are root, it just obeys what I wrote without question or
prompt. That's very dangerous.

Here's another one.

I make a link, and it is super long. I know specifically how many
characters it will take to overflow a buffer, and what comes after that
sits in your memory. That extra payload is now in your memory waiting to
be executed. Maybe I make an okay button, which you click on, which is
actually the execution of that memory. Again, you're root. So nothing
stops and asks for permission. It just does what I said. It just
executes the code in the memory location I specified. Again, I have
compromised your system.

With you running as root, it just obeys me. With you not running as
root, I request to run something which requires root is met with a
prompt asking you for permission or just failing to execute at all.
Either way, you have a chance.

You're just making it easier to be taken over. Normally I'd need some
method of escalating my privilege. Here, I'd need not bother.

See? Not nonsense at all. Running as root all the time is not smart.

[mGhost]

On 2020-04-08, F Russell <f...@random.info> wrote:

> On Wed, 08 Apr 2020 21:47:28 +0000, mGhost wrote:
>
>> It doesn't take much to open a port
>> on your machine, to a command and control service

No, I'm the service. Though I could create a service on your machine.
You already have one, and it's called CRON. Or I could just add code
that makes a service and runs it.

> Service? I have no service(s) running on my machine.

So if you run top right now, nothing comes up?

> For what do I need a service? If something needs to
> be done I do it myself.
>
> So your whole idea of exploitation is a pipe dream
> and could never happen.

No, it can still happen.

> Unix was created way back when no one had computers
> and hence they had concepts of multi-users and
> services..
>
> But in the age of PERSONAL COMPUTERS, those concepts
> no longer apply and are extremely anachronistic.
>
> Just always run as root and tell these security idiots
> to kiss off.

Nope, afraid not. Aside from Wildman and maybe one or two others,
everyone will side with me. Just watch. What you're saying is wrong.

[F Russell]

On Wed, 08 Apr 2020 22:20:45 +0000, mGhost wrote:

>
> What you're saying is wrong.
>

Talk to me in 10 years. Nothing will have happened because
nothing can happen.

It's all useless, meaningless armchair speculation.

[mGhost]

On 2020-04-08, F Russell <f...@random.info> wrote:

If nothing happens to you or your machine it will have more to do with
obscurity than your safety precautions. Your observation here is
incorrect. Sometimes what we see, fits, even though it is incorrect.

[David W. Hodgins]

On Wed, 08 Apr 2020 15:25:20 -0400, Bengt T <bengt_t...@hotmail.com> wrote:

>> Put your username and rsync in /etc/sudoers

> As I understand the following should be added into /etc/sudoers file:
> <my_user_name> ALL= /usr/bin/rsync

Use the exact path and the name of the script.

For example ...
bengt ALL = (root) NOPASSWD: /usr/local/bin/my_backup.script

Make sure the script is read only for anyone other than root.

Regards, Dave Hodgins


--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

[David W. Hodgins]

On Wed, 08 Apr 2020 18:20:45 -0400, mGhost <mGh...@mouse-potato.com> wrote:

> Nope, afraid not. Aside from Wildman and maybe one or two others,
> everyone will side with me. Just watch. What you're saying is wrong.

You seem to be one of the trolls whose purpose is to do nothing but sow
dissension, and divide people. Civil discussion is a much more productive
way of contributing.

[mGhost]

Your opinion is duly noted.

Is it or is it not a good idea to run as root all the time?

Nothing in that question is trolling in anyway. I've answered the
question with valid examples. If you disagree with the way I said it, drop
me in your killfile and be done with me. Simple as that. Otherwise, I
have no argument with you sir. Have a wonderful day. Stay safe.

[Wildman]

You keep moving the goal post. No one said anything about
running as root all the time. This thread was about running
a single script as root without sudo. Someone would have to
be a complete idiot to run their system as root. We are Linux
users, not Windows. Buy yourself an umbrella Chicken Little.

--
<Wildman> GNU/Linux user #557453

"It is by will alone I set my mind in motion. It is by the juice of
sapho that thoughts acquire speed, the lips acquire stains, the stains
become a warning. It is by will alone I set my mind in motion."
-Piter De Vries

[mGhost]

Then I misunderstood the question. My apologies.

[Ned Latham]

Bengt T wrote:

> Ned Latham wrote:
> >
> > Put your username and rsync in /etc/sudoers
>

> As I understand the following shold be added into /et/sudoers file:

>
> <my_user_name> ALL= /usr/bin/rsync
>
> Is this correct?

Yes. Note that the hostname can provide additional security,
<user_name> <host_name> = /usr/bin/rsync

And with that, you might consider passwordless operation:
<user_name> <host_name> = NOPASSWD: /usr/bin/rsync

Works a treat for me with chown, halt, reboot, mount and umount.

[Ned Latham]

F Russell wrote:
> Bengt T wrote:
> >
> > In my backup script, using rsync, some directories/files will not be processed
> > because they are only accessible by root. My way around this is to use "sudo
>
> Your "way around" should be to boot up as the root user and
> stay as the root user.
>
> For the single-user workstation this is the ONLY way.

It's madness.

> I still hear moans and groans about running as root but
> all of that security nonsense is just that: nonsense.
> They can always spout off with generalities but they
> can never provide specific examples about how a single-user
> workstation can be compromised by running as root.

cd /
rm *

[David W. Hodgins]

On Wed, 08 Apr 2020 19:50:33 -0400, mGhost <mGh...@mouse-potato.com> wrote:

> On 2020-04-08, David W. Hodgins <dwho...@nomail.afraid.org> wrote:
>> On Wed, 08 Apr 2020 18:20:45 -0400, mGhost <mGh...@mouse-potato.com> wrote:
>>
>>> Nope, afraid not. Aside from Wildman and maybe one or two others,
>>> everyone will side with me. Just watch. What you're saying is wrong.
>>
>> You seem to be one of the trolls whose purpose is to do nothing but sow
>> dissension, and divide people. Civil discussion is a much more productive
>> way of contributing.
>
> Your opinion is duly noted.
>
> Is it or is it not a good idea to run as root all the time?

Which as usual with a question that asks if something is a good idea, the
answer is that it depends on the situation.

On a system that does not have any type of connection to other systems, it
doesn't matter, and can make things easier, especially if other steps have been
taken such as having /usr is on a read only file system.

If the system has any sort of connection to a network, then running as root
defeats one level of system security. Restricting what runs as root is simply
one part of system security. Security is a process, not a product. There will
always be exceptions to rules. Proper management of the exceptions, with risk
assessment and analysis to decide what is acceptable risk in the given situation
will always over ride any given set of hard coded rules.

That's why sudo allows the system administrator to control whether or not a
given script can be run as root without a password, by selected users. It's
up to the administrator (root) to decide what is acceptable risk, and to ensure
other users, if any, are properly protected.

> Nothing in that question is trolling in anyway. I've answered the
> question with valid examples. If you disagree with the way I said it, drop
> me in your killfile and be done with me. Simple as that. Otherwise, I
> have no argument with you sir. Have a wonderful day. Stay safe.

I rarely killfile people. While I rarely respond to people I think are trolling,
there are times statements trolls post should be be countered.

[Wildman]

Accepted. No problem.

--
<Wildman> GNU/Linux user #557453

The cow died so I don't need your bull!

[mGhost]

Apparently I misunderstood the question. I'm not trying to troll you or
anyone. Have lots of respect for you, Sir. Have a wonderful day.

[Bit Twister]

On Wed, 8 Apr 2020 23:50:33 -0000 (UTC), mGhost wrote:


> Is it or is it not a good idea to run as root all the time?

It is NOT a good idea to run as root all the time.

As for the dumb asses who think they are safe because they are behind
a NAT firewall and are not running "any services", they can be cracked.

Inbound Internet method of access is for the script kiddies.
The real criminals know the more insecure mode is via a website.

How you ask? By the user downloading/running anything from the Internet.

I am not talking about code/scripts, I am talking about arf, bmp, silverlight,
flash, ico, jpg, pdf, png, gif, mpeg, MP3, WMA, WMV, MP2, TIFF, doc.. files.

I wish I had kept the link because I can not find it via google, but
several years ago there was an article about a cracked site would run
a process, on the user's computer, which would open a port and call home
and and wait for commands.

The process was only in memory. After that, is was trivial for the
the criminal to send a rootkit to the system and install it.

Once a rootkit is installed, you have no way to check the system to
see if it is infected while the system is running.

[Martyn Barclay]

On Wed, 08 Apr 2020 23:50:33 +0000, mGhost wrote:

> On 2020-04-08, David W. Hodgins <dwho...@nomail.afraid.org> wrote:
>> On Wed, 08 Apr 2020 18:20:45 -0400, mGhost <mGh...@mouse-potato.com>
>> wrote:
>>
>>> Nope, afraid not. Aside from Wildman and maybe one or two others,
>>> everyone will side with me. Just watch. What you're saying is wrong.
>>
>> You seem to be one of the trolls whose purpose is to do nothing but sow
>> dissension, and divide people. Civil discussion is a much more
>> productive way of contributing.
>
> Your opinion is duly noted.
>
> Is it or is it not a good idea to run as root all the time?

It is /not/ a "good idea" to run as root all the time.
It is IMO sheer stupidity, or ignorance.

> Nothing in that question is trolling in anyway. I've answered the question
> with valid examples. If you disagree with the way I said it, drop me in
> your killfile and be done with me. Simple as that. Otherwise, I have no
> argument with you sir. Have a wonderful day. Stay safe.

--

Debian 10.2 "Buster"

[J.O. Aho]

On 08/04/2020 23.32, F Russell wrote:
> On Wed, 08 Apr 2020 10:02:47 -0700, Bengt T wrote:
>
>> In my backup script, using rsync, some directories/files will not be processed
>> because they are only accessible by root. My way around this is to use "sudo
>>
>
> Your "way around" should be to boot up as the root user and
> stay as the root user.

Then you have lowered your system security to the level of microsoft
windows with a window run as administrator (you don't need to be logged
in as administrator).

> For the single-user workstation this is the ONLY way.

No, that is only the wrong way to do things.

> I still hear moans and groans about running as root but
> all of that security nonsense is just that: nonsense.

You remember that bug steam had a few yours around, where they got the
paths wrong, you as root would have wiped your hard drive, for everyone
one else it was your users files that was gone.

> They can always spout off with generalities but they
> can never provide specific examples about how a single-user
> workstation can be compromised by running as root.

With all the CPU vulnerabilities, a javascript can execute system
binaries, which in your case mean someone would have full control of
your system, your only luck is that Linux not as targeted as microsoft
windows.

--

//Aho

[J.O. Aho]

That one wouldn't make much of damage, as / tends to just have
directories, on the other hand the following oneliner would do what you
thought of: rm -rf /

That would be possible to execute from a javascript when someone visits
your home page.

--

//Aho

[Richard Kettlewell]

"J.O. Aho" <us...@example.net> writes:

> On 08/04/2020 20.00, Ned Latham wrote:
>> Bengt T wrote:
>>>
>>> In my backup script, using rsync, some directories/files will not be
>>> processed because they are only accessible by root. My way around this

>>> is to use "sudo my_backup.script" and provide a password.
>>>
>>> My wish is to allow execution of the backup script directly without
>>> "sudo..." and password.
>>>
>>> Is/are there any way/s to accomplish this?
>>

>> Put your username and rsync in /etc/sudoers
>

> That would be a security issue, as now you allow the user to sync any
> file, in which ever direction, so with all the vulnerabilities in
> browsers in theory a remote attacker could overwrite or create new
> files in where ever on the system.

An attacker can already do that, in the OP’s configuration. If you can
sudo to root from an account, that account is equivalent to root in
security terms. The requirement to type a password does nothing more
than slow the attacker down slightly; there are multiple ways an
attacker can arrange to capture it.

--
https://www.greenend.org.uk/rjk/

[Aragorn]

On 08.04.2020 at 22:10, F Russell scribbled:

You've apparently missed about four decades worth of evolution. This
is NOT the age of personal computers, because personal computers that
have no network connection are not being used anywhere anymore.

This is the age of interconnected workstations and servers, and the
single-user paradigm died in 1995, when the internet was made available
to the general public.

The single-user paradigm of MS-DOS was also the bane of operating
systems like Windows 95, and to a large extent even the first NT-based
Windows versions. The only single-user devices in use anymore nowadays
are smartphones. Desktops (and to a limited extent even laptops) are
multi-user workstations.

The very reason why UNIX has always been a solid operating system lies
in the fact that it was designed from the ground up as a multi-user
system with clear privilege separation and permissions.

But hey, I guess all computer scientists must be wrong and you must be
right.

<rolling eyes>

[J.O. Aho]

Yes, an attacker could figure out the local users password, it's a bit
more job than just execute a command. A small rock on the road is better
than no rock at all if you want to keep folks from using the road.

Had been nice to see a 2 factor authentication for sudo/su.

--

//Aho

[Martyn Barclay]

On Thu, 09 Apr 2020 09:28:21 +0200, J.O. Aho wrote:

> On 08/04/2020 23.32, F Russell wrote:
>> On Wed, 08 Apr 2020 10:02:47 -0700, Bengt T wrote:
>>
>>> In my backup script, using rsync, some directories/files will not be
>>> processed because they are only accessible by root. My way around this
>>> is to use "sudo
>>>
>>>
>> Your "way around" should be to boot up as the root user and stay as the
>> root user.
>
> Then you have lowered your system security to the level of microsoft
> windows with a window run as administrator (you don't need to be logged in
> as administrator).

+1

>> For the single-user workstation this is the ONLY way.
>
> No, that is only the wrong way to do things.

It is, absolutely the /wrong/ way to do things.

>> I still hear moans and groans about running as root but all of that
>> security nonsense is just that: nonsense.
>
> You remember that bug steam had a few yours around, where they got the
> paths wrong, you as root would have wiped your hard drive, for everyone
> one else it was your users files that was gone.
>
>
>> They can always spout off with generalities but they can never provide
>> specific examples about how a single-user workstation can be compromised
>> by running as root.
>
> With all the CPU vulnerabilities, a javascript can execute system
> binaries, which in your case mean someone would have full control of your
> system, your only luck is that Linux not as targeted as microsoft windows.

--

Debian 10.2 "Buster"

[Martyn Barclay]

On Thu, 09 Apr 2020 10:20:48 +0200, Aragorn wrote:

> On 08.04.2020 at 22:10, F Russell scribbled:
>
>> On Wed, 08 Apr 2020 21:47:28 +0000, mGhost wrote:
>>
>> > It doesn't take much to open a port
>> > on your machine, to a command and control service
>> >
>> >
>> Service? I have no service(s) running on my machine.

So let's see, amongst other services that /may/ be running (depending on
the desktop) according to this guy he does /not/ have running:

Apper

Cookie Jar

ColorCorrect Geolocation Updater

Hardware Detection

Free Space Notifier

Monitor Application Menus Daemon

Input Actions

Keyboard Daemon

Network Proxy Configuration

Network Status

Remote URL Change Notifier

Status Notifier Manager

Time Zone

Write Daemon

Heh.

--
Debian 10.2 "Buster"

[Jasen Betts]

On 2020-04-08, Bengt T <bengt_t...@hotmail.com> wrote:
> In my backup script, using rsync, some directories/files will not be processed because they are only accessible by root. My way around this is to use "sudo my_backup.script" and provide a password.
>
> My wish is to allow execution of the backup script directly without "sudo..." and password.
>
> Is/are there any way/s to accomplish this?

have the script sudo itself.


(( $( id -u ) )) || exec sudo "$0" "$@"


--
Jasen.

[Carlos E.R.]

On 09/04/2020 01.50, mGhost wrote:
> On 2020-04-08, David W. Hodgins <dwho...@nomail.afraid.org> wrote:
>> On Wed, 08 Apr 2020 18:20:45 -0400, mGhost <mGh...@mouse-potato.com> wrote:
>>
>>> Nope, afraid not. Aside from Wildman and maybe one or two others,
>>> everyone will side with me. Just watch. What you're saying is wrong.
>>
>> You seem to be one of the trolls whose purpose is to do nothing but sow
>> dissension, and divide people. Civil discussion is a much more productive
>> way of contributing.
>
> Your opinion is duly noted.
>
> Is it or is it not a good idea to run as root all the time?

It is a very bad idea.

--
Cheers, Carlos.

[Carlos E.R.]

On 09/04/2020 02.05, Wildman wrote:
> On Wed, 08 Apr 2020 22:15:48 +0000, mGhost wrote:
>> On 2020-04-08, Wildman <best...@yahoo.com> wrote:
>>> On Wed, 08 Apr 2020 21:47:28 +0000, mGhost wrote:
>>>> On 2020-04-08, F Russell <f...@random.info> wrote:
>>>>> On Wed, 08 Apr 2020 10:02:47 -0700, Bengt T wrote:
>>>>>> In my backup script, using rsync, some directories/files will not be processed
>>>>>> because they are only accessible by root. My way around this is to use "sudo
>>>>>>
>>>>>
>>>>> Your "way around" should be to boot up as the root user and
>>>>> stay as the root user.
>>>>>
>>>>> For the single-user workstation this is the ONLY way.
>>>>>
>>>>> I still hear moans and groans about running as root but
>>>>> all of that security nonsense is just that: nonsense.
>>>>> They can always spout off with generalities but they
>>>>> can never provide specific examples about how a single-user
>>>>> workstation can be compromised by running as root.

...

>> See? Not nonsense at all. Running as root all the time is not smart.

Yes, someone did.

> You keep moving the goal post. No one said anything about
> running as root all the time. This thread was about running
> a single script as root without sudo. Someone would have to
> be a complete idiot to run their system as root. We are Linux
> users, not Windows. Buy yourself an umbrella Chicken Little.
>

Agreed, but someone did. See the quoted text above.

--
Cheers, Carlos.

[Soviet_Mario]

On 08/04/20 21:35, Aragorn wrote:
> On 08.04.2020 at 21:30, Soviet_Mario scribbled:
>
>> On 08/04/20 19:58, Aragorn wrote:
>>> On 08.04.2020 at 19:54, Aragorn scribbled:
>>>
>>>> On 08.04.2020 at 19:20, Carlos E.R. scribbled:

>>>>
>>>>> On 08/04/2020 19.02, Bengt T wrote:
>>>>>> In my backup script, using rsync, some directories/files will not
>>>>>> be processed because they are only accessible by root. My way

>>>>>> around this is to use "sudo my_backup.script" and provide a
>>>>>> password.
>>>>>>
>>>>>> My wish is to allow execution of the backup script directly
>>>>>> without "sudo..." and password.
>>>>>>
>>>>>> Is/are there any way/s to accomplish this?
>>>>>

>>>>> Yes... making the script suid or sgid.
>>>>>
>>>>> However, that poses a security danger.
>>>>
>>>> Not really, because the Linux kernel ignores SUID/SGID on scripts.
>>>> ;)
>>>
>>> A better solution would be to set up /etc/sudoers so that the script
>>> may be executed passwordlessly — if that's not a word, then it is
>>> now :p — and perhaps create an alias or a shell function to invoke
>>> the script with the "sudo" prefix. ;)
>>>
>>>
>>
>> could you delve deeper into this ....
>> I can't understand the relation between a given script and
>> sudoers
>
> You can set the permissions in /etc/sudoers [*] so that a certain user
> can execute certain commands with root privileges without requiring a
> password. A script is a command too. :)
>
>
> [*] Read The /Fine/ Manual. :p

overwhelming ...

>


--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[Melzzzzz]

I have problem with wireshark:
I do: sudo setcap cap_net_raw,cap_net_admin+eip /usr/bin/dumpcap
but apparently I still need sudo wireshark in order to capture :(
Any clue?


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Bit Twister]

On Thu, 09 Apr 2020 14:29:04 GMT, Melzzzzz wrote:
>
> I have problem with wireshark:
> I do: sudo setcap cap_net_raw,cap_net_admin+eip /usr/bin/dumpcap
> but apparently I still need sudo wireshark in order to capture :(
> Any clue?

Based on the inordinate amount of information not provided, I'll guess
you have not added the group 'wireshark' to your login id, and
logged out/in. Do run "id" to verify you are in the wireshark group.

$ id -nG | tr ' ' '\n' | grep wire
wireshark

[Allodoxaphobia]

On Wed, 8 Apr 2020 10:02:47 -0700 (PDT), Bengt T wrote:

> In my backup script, using rsync, some directories/files will not be
> processed because they are only accessible by root. My way around this

> is to use "sudo my_backup.script" and provide a password.
>
> My wish is to allow execution of the backup script directly without
> "sudo..." and password.
>
> Is/are there any way/s to accomplish this?

I see no one has suggested cron.
Configure a cron job (script) to do what you wish.

Setting the resultant file (backup) permissions
is left as an exercise for grasshopper. :-)

Jonesy
--
Marvin L Jones | Marvin | W3DHJ.net | linux
38.238N 104.547W | @ jonz.net | Jonesy | FreeBSD
* Killfiling google & XXXXbanter.com: jonz.net/ng.htm

[Bengt T]

After reading received advises and some further reading it seems to me that I should add the information ("bengt All =...") into a new file /etc/sudoers.d/bengt.

Thank you all who contributed in answering my question.

[Allodoxaphobia]

On 9 Apr 2020 17:00:46 GMT, Allodoxaphobia wrote:
> On Wed, 8 Apr 2020 10:02:47 -0700 (PDT), Bengt T wrote:
>
>> In my backup script, using rsync, some directories/files will not be
>> processed because they are only accessible by root. My way around this
>> is to use "sudo my_backup.script" and provide a password.
>>
>> My wish is to allow execution of the backup script directly without
>> "sudo..." and password.
>>
>> Is/are there any way/s to accomplish this?
>
> I see no one has suggested cron.
> Configure a cron job (script) to do what you wish.

Sorry - Missing an important adjective:
Configure a root cron job (script) to do what you wish.