Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
check for root
7 views
Skip to first unread message
Michael Hufschmidt
Feb 10, 2012, 3:40:09 AM2/10/12
to
Hello @ all,
I have a shell script ( #!/bin/bash ) which must be executed as root,
nevertheless it is located in /usr/local/bin. How can I check within the
script that it is executed as root? If not it should echo a warning and
exit 1.
Clever ideas would be appreciated - Michael
I have a shell script ( #!/bin/bash ) which must be executed as root,
nevertheless it is located in /usr/local/bin. How can I check within the
script that it is executed as root? If not it should echo a warning and
exit 1.
Clever ideas would be appreciated - Michael
Stachu 'Dozzie' K.
Feb 10, 2012, 3:41:17 AM2/10/12
to
On 2012-02-10, Michael Hufschmidt <Michael_H...@omnis.net> wrote:
> Hello @ all,
>
> I have a shell script ( #!/bin/bash ) which must be executed as root,
> nevertheless it is located in /usr/local/bin.
What does have location to being executed as root or not?
> Hello @ all,
>
> I have a shell script ( #!/bin/bash ) which must be executed as root,
> nevertheless it is located in /usr/local/bin.
> How can I check within the
> script that it is executed as root? If not it should echo a warning and
> exit 1.
>
> Clever ideas would be appreciated - Michael
is executed?
--
Secunia non olet.
Stanislaw Klekot
Barry Margolin
Feb 10, 2012, 3:46:22 AM2/10/12
to
In article <slrnjj9m11...@jarowit.net>,
"Stachu 'Dozzie' K." <doz...@go.eat.some.screws.spammer.invalid>
wrote:
> On 2012-02-10, Michael Hufschmidt <Michael_H...@omnis.net> wrote:
> > Hello @ all,
> >
> > I have a shell script ( #!/bin/bash ) which must be executed as root,
> > nevertheless it is located in /usr/local/bin.
>
> What does have location to being executed as root or not?
Perhaps because /usr/local/sbin is a conventional location for
administrative commands.
>
> > How can I check within the
> > script that it is executed as root? If not it should echo a warning and
> > exit 1.
> >
> > Clever ideas would be appreciated - Michael
>
> And what about unclever ones? Like checking UID, under which the script
> is executed?
I think he's asking HOW to check the UID.
if [[ "$(id -u)" -ne 0 ]]
then echo "Must be run as root"
exit 1
fi
Another option is to make the script owned by root, and set the
permissions to 544, so only root can execute it.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
"Stachu 'Dozzie' K." <doz...@go.eat.some.screws.spammer.invalid>
wrote:
> On 2012-02-10, Michael Hufschmidt <Michael_H...@omnis.net> wrote:
> > Hello @ all,
> >
> > I have a shell script ( #!/bin/bash ) which must be executed as root,
> > nevertheless it is located in /usr/local/bin.
>
> What does have location to being executed as root or not?
administrative commands.
>
> > How can I check within the
> > script that it is executed as root? If not it should echo a warning and
> > exit 1.
> >
> > Clever ideas would be appreciated - Michael
>
> And what about unclever ones? Like checking UID, under which the script
> is executed?
if [[ "$(id -u)" -ne 0 ]]
then echo "Must be run as root"
exit 1
fi
Another option is to make the script owned by root, and set the
permissions to 544, so only root can execute it.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Michael Hufschmidt
Feb 10, 2012, 5:04:39 AM2/10/12
to
Am 10.02.2012 09:46 schrieb Barry Margolin:
> In article<slrnjj9m11...@jarowit.net>,
> "Stachu 'Dozzie' K."<doz...@go.eat.some.screws.spammer.invalid>
> wrote:
>
>> On 2012-02-10, Michael Hufschmidt<Michael_H...@omnis.net> wrote:
>>> Hello @ all,
>>>
>>> I have a shell script ( #!/bin/bash ) which must be executed as root,
>>> nevertheless it is located in /usr/local/bin.
>>
>> What does have location to being executed as root or not?
>
> Perhaps because /usr/local/sbin is a conventional location for
> administrative commands.
>
>>
>>> How can I check within the
>>> script that it is executed as root? If not it should echo a warning and
>>> exit 1.
>>>
>>> Clever ideas would be appreciated - Michael
>>
>> And what about unclever ones? Like checking UID, under which the script
>> is executed?
>
> I think he's asking HOW to check the UID.
>
> if [[ "$(id -u)" -ne 0 ]]
> then echo "Must be run as root"
> exit 1
> fi
>
> Another option is to make the script owned by root, and set the
> permissions to 544, so only root can execute it.
>
Thank you Stanislaw and Barry! I have included the
> In article<slrnjj9m11...@jarowit.net>,
> "Stachu 'Dozzie' K."<doz...@go.eat.some.screws.spammer.invalid>
> wrote:
>
>> On 2012-02-10, Michael Hufschmidt<Michael_H...@omnis.net> wrote:
>>> Hello @ all,
>>>
>>> I have a shell script ( #!/bin/bash ) which must be executed as root,
>>> nevertheless it is located in /usr/local/bin.
>>
>> What does have location to being executed as root or not?
>
> Perhaps because /usr/local/sbin is a conventional location for
> administrative commands.
>
>>
>>> How can I check within the
>>> script that it is executed as root? If not it should echo a warning and
>>> exit 1.
>>>
>>> Clever ideas would be appreciated - Michael
>>
>> And what about unclever ones? Like checking UID, under which the script
>> is executed?
>
> I think he's asking HOW to check the UID.
>
> if [[ "$(id -u)" -ne 0 ]]
> then echo "Must be run as root"
> exit 1
> fi
>
> Another option is to make the script owned by root, and set the
> permissions to 544, so only root can execute it.
>
if [[ "$(id -u)" -ne 0 ]]
in my script and it works just fine.
Michael (now happy)
Thomas 'PointedEars' Lahn
Feb 10, 2012, 6:40:40 AM2/10/12
to
Barry Margolin wrote:
> if [[ "$(id -u)" -ne 0 ]]
> then echo "Must be run as root"
> exit 1
> fi
Is
> if [[ "$(id -u)" -ne 0 ]]
> then echo "Must be run as root"
> exit 1
> fi
if [ 0 -ne $(id -u) ]
too compatible or too efficient?
--
PointedEars
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Stephane Chazelas
Feb 10, 2012, 6:54:13 AM2/10/12
to
2012-02-10 12:40:40 +0100, Thomas 'PointedEars' Lahn:
Not portable enough. For instance, can't be ported to contexts
where $IFS contains digits.
if [ 0 -ne "$(id -u)" ]
Note that bash (the OP mentionned bash) has a $EUID builtin
variable. Unfortunately though, contrary to zsh, an environ by
the same name overrides it which makes it unsafe to use
reliably:
~$ env -i bash -c 'echo $EUID'
1000
~$ env -i EUID=0 bash -c 'echo $EUID'
0
~$ env -i zsh -c 'echo $EUID'
1000
~$ env -i EUID=0 zsh -c 'echo $EUID'
1000
--
Stephane
> Barry Margolin wrote:
>
> > if [[ "$(id -u)" -ne 0 ]]
> > then echo "Must be run as root"
> > exit 1
> > fi
>
> Is
>
> if [ 0 -ne $(id -u) ]
>
> too compatible or too efficient?
[...]
>
> > if [[ "$(id -u)" -ne 0 ]]
> > then echo "Must be run as root"
> > exit 1
> > fi
>
> Is
>
> if [ 0 -ne $(id -u) ]
>
> too compatible or too efficient?
Not portable enough. For instance, can't be ported to contexts
where $IFS contains digits.
if [ 0 -ne "$(id -u)" ]
variable. Unfortunately though, contrary to zsh, an environ by
the same name overrides it which makes it unsafe to use
reliably:
~$ env -i bash -c 'echo $EUID'
1000
~$ env -i EUID=0 bash -c 'echo $EUID'
0
~$ env -i zsh -c 'echo $EUID'
1000
~$ env -i EUID=0 zsh -c 'echo $EUID'
1000
--
Stephane
Thomas 'PointedEars' Lahn
Feb 10, 2012, 7:08:02 AM2/10/12
to
Stephane Chazelas wrote:
> 2012-02-10 12:40:40 +0100, Thomas 'PointedEars' Lahn:
>> Barry Margolin wrote:
>> > if [[ "$(id -u)" -ne 0 ]]
>> > then echo "Must be run as root"
>> > exit 1
>> > fi
>>
>> Is
>>
>> if [ 0 -ne $(id -u) ]
>>
>> too compatible or too efficient?
> [...]
>
> Not portable enough. For instance, can't be ported to contexts
> where $IFS contains digits.
Far-fetched.
> 2012-02-10 12:40:40 +0100, Thomas 'PointedEars' Lahn:
>> Barry Margolin wrote:
>> > if [[ "$(id -u)" -ne 0 ]]
>> > then echo "Must be run as root"
>> > exit 1
>> > fi
>>
>> Is
>>
>> if [ 0 -ne $(id -u) ]
>>
>> too compatible or too efficient?
> [...]
>
> Not portable enough. For instance, can't be ported to contexts
> where $IFS contains digits.
> if [ 0 -ne "$(id -u)" ]
> Note that bash (the OP mentionned bash)
little effort?
> has a $EUID builtin variable. Unfortunately though, contrary to zsh, an
> environ by the same name overrides it which makes it unsafe to use
> reliably:
>
> ~$ env -i bash -c 'echo $EUID'
> 1000
> ~$ env -i EUID=0 bash -c 'echo $EUID'
> 0
> ~$ env -i zsh -c 'echo $EUID'
> 1000
> ~$ env -i EUID=0 zsh -c 'echo $EUID'
> 1000
read-only. There is also $UID with the same property.
JFTR: I would only use the *negated* test to *prevent* root from running a
potentially harmful user script (it has been done before). Scripts that
*only* root can run simply belong in /usr/sbin oder /usr/local/sbin and
should have appropriate permissions and ownership set.
Stachu 'Dozzie' K.
Feb 10, 2012, 7:20:12 AM2/10/12
to
On 2012-02-10, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
[...]
by root?
It's not the way to go, to limit what root can run. Just minimize the
number of tasks performed under root account.
> Scripts that
> *only* root can run simply belong in /usr/sbin oder /usr/local/sbin and
> should have appropriate permissions and ownership set.
And now compare this to: xfs_freeze, hping2/hping3, usermod, exportfs
(Debian Squeeze, in my case). All from /usr/sbin. None have sense to be
ran as non-root. All have RX permissions for all users. It doesn't
matter most of them (except for xfs_freeze) are binaries.
[...]
> JFTR: I would only use the *negated* test to *prevent* root from running a
> potentially harmful user script (it has been done before).
/bin/rm is also potentially harmful. Do you want it not to be runnable
> potentially harmful user script (it has been done before).
by root?
It's not the way to go, to limit what root can run. Just minimize the
number of tasks performed under root account.
> Scripts that
> *only* root can run simply belong in /usr/sbin oder /usr/local/sbin and
> should have appropriate permissions and ownership set.
(Debian Squeeze, in my case). All from /usr/sbin. None have sense to be
ran as non-root. All have RX permissions for all users. It doesn't
matter most of them (except for xfs_freeze) are binaries.
Geoff Clare
Feb 10, 2012, 8:26:52 AM2/10/12
to
Barry Margolin wrote:
> if [[ "$(id -u)" -ne 0 ]]
> then echo "Must be run as root"
> exit 1
> fi
>
> Another option is to make the script owned by root, and set the
> permissions to 544, so only root can execute it.
Make that permission 500. A user who can read it can execute it
> if [[ "$(id -u)" -ne 0 ]]
> then echo "Must be run as root"
> exit 1
> fi
>
> Another option is to make the script owned by root, and set the
> permissions to 544, so only root can execute it.
using "sh scriptname".
--
Geoff Clare <net...@gclare.org.uk>
Ben Bacarisse
Feb 10, 2012, 8:47:20 AM2/10/12
to
Barry Margolin <bar...@alum.mit.edu> writes:
<snip>
> Another option is to make the script owned by root, and set the
> permissions to 544, so only root can execute it.
Yes, though it can still be "sourced". That's not, technically, being
executed, but for all practical purposes one would want to exclude that
possibility also (by using 500 instead, for example).
--
Ben.
<snip>
>> On 2012-02-10, Michael Hufschmidt <Michael_H...@omnis.net> wrote:
<snip>
>> > I have a shell script ( #!/bin/bash ) which must be executed as root,
<snip>
> Another option is to make the script owned by root, and set the
> permissions to 544, so only root can execute it.
executed, but for all practical purposes one would want to exclude that
possibility also (by using 500 instead, for example).
--
Ben.
Thomas 'PointedEars' Lahn
Feb 10, 2012, 11:03:04 AM2/10/12
to
Ben Bacarisse wrote:
> Barry Margolin <bar...@alum.mit.edu> writes:
>>> On 2012-02-10, Michael Hufschmidt <Michael_H...@omnis.net> wrote:
>>> > I have a shell script ( #!/bin/bash ) which must be executed as root,
So set the file permissions and ownership correctly (chmod 770; chown
root.root), put it where it belongs (/usr/sbin, or /usr/local/sbin if not
from a package), and you will be fine.
> Barry Margolin <bar...@alum.mit.edu> writes:
>>> On 2012-02-10, Michael Hufschmidt <Michael_H...@omnis.net> wrote:
>>> > I have a shell script ( #!/bin/bash ) which must be executed as root,
>> Another option is to make the script owned by root, and set the
>> permissions to 544, so only root can execute it.
>
> Yes, though it can still be "sourced". That's not, technically, being
> executed, but for all practical purposes one would want to exclude that
> possibility also (by using 500 instead, for example).
A script that also can only be read by root cannot be sourced by non-root.
>> permissions to 544, so only root can execute it.
>
> Yes, though it can still be "sourced". That's not, technically, being
> executed, but for all practical purposes one would want to exclude that
> possibility also (by using 500 instead, for example).
So set the file permissions and ownership correctly (chmod 770; chown
root.root), put it where it belongs (/usr/sbin, or /usr/local/sbin if not
from a package), and you will be fine.
Barry Margolin
Feb 10, 2012, 6:25:40 PM2/10/12
to
In article <shif09-...@leafnode-msgid.gclare.org.uk>,
execution, so it's not necessary to worry about cases like that. After
all, if he uses the ID check in the script, someone could simply copy
the script and remove the check.
It's not like there's a security reason for these checks, it's usually
just a sanity check.
Geoff Clare <ge...@clare.See-My-Signature.invalid> wrote:
> Barry Margolin wrote:
>
> > if [[ "$(id -u)" -ne 0 ]]
> > then echo "Must be run as root"
> > exit 1
> > fi
> >
> > Another option is to make the script owned by root, and set the
> > permissions to 544, so only root can execute it.
>
> Make that permission 500. A user who can read it can execute it
> using "sh scriptname".
In most situations like this, the goal is to prevent accidental
> Barry Margolin wrote:
>
> > if [[ "$(id -u)" -ne 0 ]]
> > then echo "Must be run as root"
> > exit 1
> > fi
> >
> > Another option is to make the script owned by root, and set the
> > permissions to 544, so only root can execute it.
>
> Make that permission 500. A user who can read it can execute it
> using "sh scriptname".
execution, so it's not necessary to worry about cases like that. After
all, if he uses the ID check in the script, someone could simply copy
the script and remove the check.
It's not like there's a security reason for these checks, it's usually
just a sanity check.
Thomas 'PointedEars' Lahn
Feb 10, 2012, 6:58:06 PM2/10/12
to
Stachu 'Dozzie' K. wrote:
> Thomas 'PointedEars' Lahn wrote:
>> JFTR: I would only use the *negated* test to *prevent* root from running
>> a potentially harmful user script (it has been done before).
>
> /bin/rm is also potentially harmful. Do you want it not to be runnable
> by root?
False dilemma. /bin/rm is a binary, not a user script.
> It's not the way to go, to limit what root can run. Just minimize the
> number of tasks performed under root account.
Again, false dilemma. Both measures are appropriate.
>> Scripts that *only* root can run simply belong in /usr/sbin oder
>> /usr/local/sbin and should have appropriate permissions and ownership
>> set.
>
> And now compare this to: xfs_freeze, hping2/hping3, usermod, exportfs
> (Debian Squeeze, in my case). All from /usr/sbin. None have sense to be
> ran as non-root. All have RX permissions for all users. It doesn't
> matter most of them (except for xfs_freeze) are binaries.
Your logic is flawed.
Your From header field value is violating RFC 5536 and perhaps the
Acceptable Use Policy of your access provider. Please fix it.
> Thomas 'PointedEars' Lahn wrote:
>> JFTR: I would only use the *negated* test to *prevent* root from running
>> a potentially harmful user script (it has been done before).
>
> /bin/rm is also potentially harmful. Do you want it not to be runnable
> by root?
> It's not the way to go, to limit what root can run. Just minimize the
> number of tasks performed under root account.
>> Scripts that *only* root can run simply belong in /usr/sbin oder
>> /usr/local/sbin and should have appropriate permissions and ownership
>> set.
>
> And now compare this to: xfs_freeze, hping2/hping3, usermod, exportfs
> (Debian Squeeze, in my case). All from /usr/sbin. None have sense to be
> ran as non-root. All have RX permissions for all users. It doesn't
> matter most of them (except for xfs_freeze) are binaries.
Your From header field value is violating RFC 5536 and perhaps the
Acceptable Use Policy of your access provider. Please fix it.
Stachu 'Dozzie' K.
Feb 11, 2012, 7:42:14 AM2/11/12
to
On 2012-02-10, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
> Stachu 'Dozzie' K. wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> JFTR: I would only use the *negated* test to *prevent* root from running
>>> a potentially harmful user script (it has been done before).
>>
>> /bin/rm is also potentially harmful. Do you want it not to be runnable
>> by root?
>
> False dilemma. /bin/rm is a binary, not a user script.
In what way binary differs from a script? Except for programming
>
>> Thomas 'PointedEars' Lahn wrote:
>>> JFTR: I would only use the *negated* test to *prevent* root from running
>>> a potentially harmful user script (it has been done before).
>>
>> /bin/rm is also potentially harmful. Do you want it not to be runnable
>> by root?
>
> False dilemma. /bin/rm is a binary, not a user script.
language.
>> It's not the way to go, to limit what root can run. Just minimize the
>> number of tasks performed under root account.
>
> Again, false dilemma. Both measures are appropriate.
appropriate.
>>> Scripts that *only* root can run simply belong in /usr/sbin oder
>>> /usr/local/sbin and should have appropriate permissions and ownership
>>> set.
>>
>> And now compare this to: xfs_freeze, hping2/hping3, usermod, exportfs
>> (Debian Squeeze, in my case). All from /usr/sbin. None have sense to be
>> ran as non-root. All have RX permissions for all users. It doesn't
>> matter most of them (except for xfs_freeze) are binaries.
>
> Your logic is flawed.
Your statement is flawed.
>>> Scripts that *only* root can run simply belong in /usr/sbin oder
>>> /usr/local/sbin and should have appropriate permissions and ownership
>>> set.
>>
>> And now compare this to: xfs_freeze, hping2/hping3, usermod, exportfs
>> (Debian Squeeze, in my case). All from /usr/sbin. None have sense to be
>> ran as non-root. All have RX permissions for all users. It doesn't
>> matter most of them (except for xfs_freeze) are binaries.
>
> Your logic is flawed.
We can argue in the same manner for quite a long time, but I guess you
have no technical arguments. Let me end conversation with you here.
> Your From header field value is violating RFC 5536
doesn't specify in which DNS network do I need to own this mailbox.
> and perhaps the
> Acceptable Use Policy of your access provider. Please fix it.
--
Kenny McCormack
Feb 11, 2012, 9:08:43 AM2/11/12
to
In article <slrnjjcogr...@jarowit.net>,
distribution. "User" scripts are not trusted, because they are written by,
well, users.
As for the rest of this post, Stachu, you should know by now that arguing
with the Pointy one is arguing with an idiot. Amusing and entertaining, but
don't take it too seriously.
--
First of all, I do not appreciate your playing stupid here at all.
- Thomas 'PointedEars' Lahn -
Stachu 'Dozzie' K. <doz...@go.eat.some.screws.spammer.invalid> wrote:
>On 2012-02-10, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>> Stachu 'Dozzie' K. wrote:
>>
>>> Thomas 'PointedEars' Lahn wrote:
>>>> JFTR: I would only use the *negated* test to *prevent* root from running
>>>> a potentially harmful user script (it has been done before).
>>>
>>> /bin/rm is also potentially harmful. Do you want it not to be runnable
>>> by root?
>>
>> False dilemma. /bin/rm is a binary, not a user script.
>
>In what way binary differs from a script? Except for programming
>language.
The implication is that 'rm' is trusted because it comes with the
>> Stachu 'Dozzie' K. wrote:
>>
>>> Thomas 'PointedEars' Lahn wrote:
>>>> JFTR: I would only use the *negated* test to *prevent* root from running
>>>> a potentially harmful user script (it has been done before).
>>>
>>> /bin/rm is also potentially harmful. Do you want it not to be runnable
>>> by root?
>>
>> False dilemma. /bin/rm is a binary, not a user script.
>
>In what way binary differs from a script? Except for programming
>language.
distribution. "User" scripts are not trusted, because they are written by,
well, users.
As for the rest of this post, Stachu, you should know by now that arguing
with the Pointy one is arguing with an idiot. Amusing and entertaining, but
don't take it too seriously.
--
First of all, I do not appreciate your playing stupid here at all.
- Thomas 'PointedEars' Lahn -
stan
Feb 11, 2012, 2:05:51 PM2/11/12
to
Stachu 'Dozzie' K. wrote:
> On 2012-02-10, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>>>> JFTR: I would only use the *negated* test to *prevent* root from running
>>>> a potentially harmful user script (it has been done before).
>>>
>>> /bin/rm is also potentially harmful. Do you want it not to be runnable
>>> by root?
>>
>> False dilemma. /bin/rm is a binary, not a user script.
>
> In what way binary differs from a script? Except for programming
> language.
In context I have no relevant ideas. In a bigger picture, the attacks
> On 2012-02-10, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>>>> JFTR: I would only use the *negated* test to *prevent* root from running
>>>> a potentially harmful user script (it has been done before).
>>>
>>> /bin/rm is also potentially harmful. Do you want it not to be runnable
>>> by root?
>>
>> False dilemma. /bin/rm is a binary, not a user script.
>
> In what way binary differs from a script? Except for programming
> language.
against binaries and scripts are different so there are security
related differences but those differences don't seem important in the
given context.
I understood the question or problem domain was to control access to a
single script. The motives don't seem to matter much. If the problem
is to secure the system that seems like a different problem. The
thread seemed to jump track by assuming a motive and redefining the
problem.
Stachu 'Dozzie' K.
Feb 11, 2012, 2:18:03 PM2/11/12
to
On 2012-02-11, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> As for the rest of this post, Stachu, you should know by now that arguing
> with the Pointy one is arguing with an idiot. Amusing and entertaining, but
> don't take it too seriously.
Well, I found that out and updated my score file. Thanks.
> As for the rest of this post, Stachu, you should know by now that arguing
> with the Pointy one is arguing with an idiot. Amusing and entertaining, but
> don't take it too seriously.
Thomas 'PointedEars' Lahn
Feb 11, 2012, 3:23:33 PM2/11/12
to
Stachu 'Dozzie' K. wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Your From header field value is violating RFC 5536
>
> Proove it. Proove that I don't own such mailbox.
That's _prove_, idiot. (Now you need to call me a "looser".)
> Thomas 'PointedEars' Lahn wrote:
>> Your From header field value is violating RFC 5536
>
> Proove it. Proove that I don't own such mailbox.
`invalid' is a top-level domain reserved for testing purposes. There cannot
be a properly used mailbox with that top-level domain because that would
defy that purpose. However, if in your network there was a mailbox with
`invalid' TLD, and it could receive mail sent from within your local
network, either you would be testing e-mail or your network configuration
would violate RFC 2606. In any event it would not be acceptable for use in
a normal Usenet posting.
> Remember that RFC 5536 doesn't specify in which DNS network do I need to
> own this mailbox.
makes no exceptions thereto. And when you post to a world-wide distributed
network like Usenet, and are not testing e-mail, it needs to be able receive
mail from everywhere, not just from within your network, the anti-social
nature of such a header field value aside.
But you probably knew that already. Now, the truth is where it needs to be.
Not expecting you to see it, I am not going to waste more time on you.
FOAD.
Kenny McCormack
Feb 11, 2012, 3:35:01 PM2/11/12
to
In article <25562608....@PointedEars.de>,
Thomas 'PointedEars' Lahn <use...@PointedEars.de> bloviated:
...
--
But the Bush apologists hope that you won't remember all that. And they
also have a theory, which I've been hearing more and more - namely,
that President Obama, though not yet in office or even elected, caused the
2008 slump. You see, people were worried in advance about his future
policies, and that's what caused the economy to tank. Seriously.
(Paul Krugman - Addicted to Bush)
Thomas 'PointedEars' Lahn <use...@PointedEars.de> bloviated:
...
>But you probably knew that already. Now, the truth is where it needs to be.
>Not expecting you to see it, I am not going to waste more time on you.
>FOAD.
Somebody really did not get enough love as a child.
>Not expecting you to see it, I am not going to waste more time on you.
>FOAD.
--
But the Bush apologists hope that you won't remember all that. And they
also have a theory, which I've been hearing more and more - namely,
that President Obama, though not yet in office or even elected, caused the
2008 slump. You see, people were worried in advance about his future
policies, and that's what caused the economy to tank. Seriously.
(Paul Krugman - Addicted to Bush)
Thomas 'PointedEars' Lahn
Feb 11, 2012, 3:41:59 PM2/11/12
to
stan wrote:
> I understood the question or problem domain was to control access to a
> single script. The motives don't seem to matter much. If the problem
> is to secure the system that seems like a different problem. The
> thread seemed to jump track by assuming a motive and redefining the
> problem.
The motives do not matter. The question does. Remember, the question was:
> I understood the question or problem domain was to control access to a
> single script. The motives don't seem to matter much. If the problem
> is to secure the system that seems like a different problem. The
> thread seemed to jump track by assuming a motive and redefining the
> problem.
| I have a shell script ( #!/bin/bash ) which must be executed as root,
| nevertheless it is located in /usr/local/bin.
root do not belong in /usr/local/bin. They belong in /usr/local/sbin.
| How can I check within the script that it is executed as root?
root if only root can execute it.
| If not it should echo a warning and exit 1.
descriptive permission error message in $LANGUAGE to stderr, and afterwards
the exit status ($?) is 126 (close enough, but if you insist: [ $? -eq 126 ]
&& exit 1).
So the best answer that can be given to this question is: "Do not do this."
Which happened.
Usenet is not the answer to your question. And that is good so.
HTH
stan
Feb 11, 2012, 11:38:06 PM2/11/12
to
Thomas 'PointedEars' Lahn wrote:
> stan wrote:
>
>> I understood the question or problem domain was to control access to a
>> single script. The motives don't seem to matter much. If the problem
>> is to secure the system that seems like a different problem. The
>> thread seemed to jump track by assuming a motive and redefining the
>> problem.
>
> The motives do not matter. The question does. Remember, the question was:
>
>| I have a shell script ( #!/bin/bash ) which must be executed as root,
>| nevertheless it is located in /usr/local/bin.
>
> That is a *mistake*, plain and simple. Scripts that *must* be executed as
> root do not belong in /usr/local/bin. They belong in /usr/local/sbin.
Unless the boss says put them somewhere else. There could be many
> stan wrote:
>
>> I understood the question or problem domain was to control access to a
>> single script. The motives don't seem to matter much. If the problem
>> is to secure the system that seems like a different problem. The
>> thread seemed to jump track by assuming a motive and redefining the
>> problem.
>
> The motives do not matter. The question does. Remember, the question was:
>
>| I have a shell script ( #!/bin/bash ) which must be executed as root,
>| nevertheless it is located in /usr/local/bin.
>
> That is a *mistake*, plain and simple. Scripts that *must* be executed as
> root do not belong in /usr/local/bin. They belong in /usr/local/sbin.
reasons for swimming upstream and diverging from best practices. It's
generally useful to note the divergence but then I see no reason not
to solve the OP's problem as stated; even when the OP is diverging
from best practice and doesn't feel obligated to address the motives
for the divergence.
I took the word "nevertheless" as a clue the OP was aware of the
divergence but wanted a solution that fit local practice vs best
practice. Labels like *mistake* seem to assume the OP wants a general
security solution. Sometimes suboptimal is the norm.
Aragorn
Feb 12, 2012, 1:22:55 AM2/12/12
to
On Saturday 11 February 2012 21:23, Thomas 'PointedEars' Lahn conveyed
the following to comp.unix.shell...
> RFC 5536 refers to RFC 5322 where it says "A mailbox receives mail.",
> and makes no exceptions thereto. And when you post to a world-wide
> distributed network like Usenet, and are not testing e-mail, it needs
> to be able receive mail from everywhere, not just from within your
> network, the anti-social nature of such a header field value aside.
I guess you've never heard of a phenomenon called "e-mail address
harvester bot" then?
Using ".invalid" as the TLD for your e-mail address is _perfectly_
legitimate on Usenet as a way to avoid being harvested and stored in a
spammer database. It conforms with the netiquette, and it's far more
ethical than using a fake e-mail address under a domain name which
doesn't belong to you, because then the owner of that domain will be
receiving spam on account of your Usenet activities.
--
= Aragorn =
(registered GNU/Linux user #223157)
the following to comp.unix.shell...
> RFC 5536 refers to RFC 5322 where it says "A mailbox receives mail.",
> and makes no exceptions thereto. And when you post to a world-wide
> distributed network like Usenet, and are not testing e-mail, it needs
> to be able receive mail from everywhere, not just from within your
> network, the anti-social nature of such a header field value aside.
harvester bot" then?
Using ".invalid" as the TLD for your e-mail address is _perfectly_
legitimate on Usenet as a way to avoid being harvested and stored in a
spammer database. It conforms with the netiquette, and it's far more
ethical than using a fake e-mail address under a domain name which
doesn't belong to you, because then the owner of that domain will be
receiving spam on account of your Usenet activities.
--
= Aragorn =
(registered GNU/Linux user #223157)
0 new messages