execution attribute of some scripts will lost after rebooting os.

[Hongyi Zhao]

Hi all,

I've a script, say, named as myscript.sh in my home directory with the
execution bit set by `chmod +x myscript.sh'.

But, after I reboot my OS, I often find that the execution attribute of
this script lost automatically.

Any hints on this issue?

Regards
--
.: Hongyi Zhao [ hongyi.zhao AT gmail.com ] Free as in Freedom :.

[Helmut Schellong]

On 09/13/15 07:19, Hongyi Zhao wrote:
> Hi all,
>
> I've a script, say, named as myscript.sh in my home directory with the
> execution bit set by `chmod +x myscript.sh'.
>
> But, after I reboot my OS, I often find that the execution attribute of
> this script lost automatically.
>
> Any hints on this issue?

Test this by adding further files in that directory, and a copy of the
script with a different name.
Who can execute automatically the command chmod?
(Search with 'find')
I have never watched such event.


--
With best regards
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm

[Hongyi Zhao]

On Sun, 13 Sep 2015 10:01:22 +0200, Helmut Schellong wrote:

> Who can execute automatically the command chmod?
> (Search with 'find')

How to do the finding for this type of job?

[Kenny McCormack]

In article <mt3pi7$73k$1...@aspen.stu.neva.ru>,

Hongyi Zhao <hongy...@gmail.com> wrote:
>On Sun, 13 Sep 2015 10:01:22 +0200, Helmut Schellong wrote:
>
>> Who can execute automatically the command chmod?
>> (Search with 'find')
>
>How to do the finding for this type of job?

Is it possible that the file is stored on some kind of non-Unix filesystem
(e.g., FAT)? That might have the attribute of not saving the full Unix set
of permission bits.

--
Rich people pay Fox people to convince middle class people to blame poor people.

(John Fugelsang)

[Hongyi Zhao]

On Sun, 13 Sep 2015 12:51:22 +0000, Kenny McCormack wrote:

> Is it possible that the file is stored on some kind of non-Unix
> filesystem (e.g., FAT)? That might have the attribute of not saving the
> full Unix set of permission bits.

No, the filesystem is ext4.

The strange thing is that sometimes I noticed that the execution
attribute lost, the chance is rare.

And I cann't figure out how to reproduce this issue.

Maybe it's raised from some bug or incompatibility in my OS -- Debian
jessie -- which is a more recent release and not experienced enough
testings.

[Aragorn]

On Sunday 13 Sep 2015 14:59, Hongyi Zhao conveyed the following to
comp.unix.shell...

> On Sun, 13 Sep 2015 12:51:22 +0000, Kenny McCormack wrote:
>
>> Is it possible that the file is stored on some kind of non-Unix
>> filesystem (e.g., FAT)? That might have the attribute of not saving
>> the full Unix set of permission bits.
>
> No, the filesystem is ext4.
>
> The strange thing is that sometimes I noticed that the execution
> attribute lost, the chance is rare.
>
> And I cann't figure out how to reproduce this issue.
>
> Maybe it's raised from some bug or incompatibility in my OS -- Debian
> jessie -- which is a more recent release and not experienced enough
> testings.

Debian Jessie is the current Debian stable branch, so that's about as
thoroughly tested as it gets.

My guess is that you may be experiencing hardware problems. Possibly
the degradation of your hard disk. Use the smartmontools package if you
suspect that the disk may be dying. Also check whether the cables are
all still properly seated.

However, it may also be more innocent, e.g. a flipped bit somewhere due
to cosmic radiation or EM fields. A clean shutdown and power-off ─ with
the power cable unplugged from the system for about 10-15 minutes ─
followed by a new cold boot should remedy this, normally.

The only way to thoroughly protect your system from EM fields is to put
it inside a Faraday cage, but the best way to protect you from all
environmentally caused digital corruption would be to invest in a system
with ECC, and specifically ECC registered DRAM.

I would either way recommend booting up from a Live CD and run
"badblocks" on your entire hard disk. Depending on the capacity of your
disk, this may be a very time-consuming process. Also run memtest86 on
your system ─ I'm assuming that it's an x86 architecture ─ and let it
run overnight just to make sure. It may not actually find errors even
if there are any, but if it _does_ find errors, then they will never be
false positives, so then it's time to replace that particular RAM
module.

Also, if you suspect that some process is messing with your permissions,
you can try any of the following...:

1. Run a grep for "chmod" throughout your entire /etc tree.

2. Check whether the filesystem in question is mounted with "noexec".
This would normally not unset the execute permission, but would
rather prevent a file with execute permission being executed.

3. In relation to filesystem damage ─ which may or may not have been
caused by a hardware fault ─ run fsck on the filesystem, preferably
from a rescue CD, so that you can be sure that nothing on the disk
itself is mounted. It is possible ─ depending on your machine's
specific configuration ─ that the filesystem automatically gets
remounted read-only when the system detects that there are
inconsistencies between the virtual filesystem layer and the
physical filesystem, e.g. after an unclean shutdown.

4. Check your system logs. As I understand it, Debian Jessie uses
systemd as a replacement for System V init, which means that your
system logger is probably going to be journald, which stores the
logs in a binary format. You can check the logs using the command
"journalctl" ─ it has a man page, and I don't use systemd on my
system, so I cannot give you the exact syntax.

5. Trace back your own steps. It is possible that you forgot to
set the execute permission on the file, or that you did it while
working under another UID ─ e.g. by using su or sudo ─ in which
case the file might have execute permission, but not for the
account from which you were trying to execute it.

--
= Aragorn =

http://www.linuxcounter.net - registrant #223157

[Helmut Schellong]

On 09/13/15 14:18, Hongyi Zhao wrote:
> On Sun, 13 Sep 2015 10:01:22 +0200, Helmut Schellong wrote:
>
>> Who can execute automatically the command chmod?
>> (Search with 'find')
>
> How to do the finding for this type of job?

mode after +x: -rwxr-xr-x
mode after boot: -rw-r--r-- all x deleted?

One example:
find /etc -follow -type f -exec grep -nH -e '\<chmod\>' {} \;

Hardware errors are possible, but they do not pick
just file mode x-bits, they sprinkle:
illegal instruction, system freeze, and so on.

[Janis Papanagnou]

Am 13.09.2015 um 08:19 schrieb Hongyi Zhao:
> Hi all,
>
> I've a script, say, named as myscript.sh in my home directory with the
> execution bit set by `chmod +x myscript.sh'.

Postings that start with "I've a script, say, ..." make me wary; such
posts may not reflect the reality. And they may lead to other folks
wasting their time. Try to be exact and copy/paste exact data. Chances
are too high that you just made a mistake or misobserved.

>
> But, after I reboot my OS, I often find that the execution attribute of
> this script lost automatically.

"I *often* find" is also a not helpful formulation; it signals that
either there's a irregularity (non-reproducable strange problem), or
that you made some mistake yourself in such cases. Try to reliably
reproduce what you think to have observed. Inspect your shell history
files. Inspect your systems cronjobs.

>
> Any hints on this issue?

My first thought when I read this was that the script was a SUID script
and the OS (or the distribution) may have some means active to remove
all 's' and 'x' flags from such scripts. (At times back when there were
no preventions to execute SUID scripts I recall that one of my "bypass
lacking root priviledge" scripts got some permission flags removed, but
that had been done by the admins manually through a 'find' based cronjob
at that time.)

You should probably provide more information to rule out assumptions;
e.g. what shows ls -l myscript.sh immediately before reboot and
immediately afterwards, what processes are running on startup and on
shutdown.

Janis

>
> Regards
>

[Kenny McCormack]

In article <mt4uqm$bom$1...@speranza.aioe.org>,

Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>Am 13.09.2015 um 08:19 schrieb Hongyi Zhao:
>> Hi all,
>>
>> I've a script, say, named as myscript.sh in my home directory with the
>> execution bit set by `chmod +x myscript.sh'.
>
>Postings that start with "I've a script, say, ..." make me wary; such
>posts may not reflect the reality. And they may lead to other folks
>wasting their time. Try to be exact and copy/paste exact data. Chances
>are too high that you just made a mistake or misobserved.

Janis, you should know by now that all Hongyi Zhao posts are of the form:

I did something and had an impossible and non-reproducible result.
I want you to expend energy making blind guesses as to what it was and
why it happened.

It has been thus for as long as he has been posting to this newsgroup.

Now, the above is the cynical version of it. The less cynical version is
something like:

I'm a perennial newbie. If I had any diagnostic skills - including the
ability to accurately describe my problems - I wouldn't be a newbie.
As such, my postings are as accurate as they can be or ever will be.
You need to accept this fact of life and life with it. I am, so you
can too. Believe me, if I could do better, I would. Seriously!

--
Modern Conservative: Someone who can take time out
from demanding more flag burning laws, more abortion
laws, more drug laws, more obscenity laws, and more
police authority to make warrantless arrests to remind
us that we need to "get the government off our backs".

[Kaz Kylheku]

On 2015-09-14, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>
> I'm a perennial newbie. If I had any diagnostic skills - including the
> ability to accurately describe my problems - I wouldn't be a newbie.
> As such, my postings are as accurate as they can be or ever will be.
> You need to accept this fact of life and life with it. I am, so you
> can too. Believe me, if I could do better, I would. Seriously!

P.S. the ten line regex you gave me for matching host names
fails on such and such example. Plz fix! ... Ta ta!

[Dan Espen]

Hongyi Zhao <hongy...@gmail.com> writes:

> Hi all,
>
> I've a script, say, named as myscript.sh in my home directory with the
> execution bit set by `chmod +x myscript.sh'.
>
> But, after I reboot my OS, I often find that the execution attribute of
> this script lost automatically.
>
> Any hints on this issue?

I'd suspect your profile rather than anything that happens with a
reboot.

Maybe look at /etc/bash* too.

--
Dan Espen

[Jim Beard]

On Sun, 13 Sep 2015 05:19:32 +0000, Hongyi Zhao wrote:

> Hi all,
>
> I've a script, say, named as myscript.sh in my home directory with the
> execution bit set by `chmod +x myscript.sh'.
>
> But, after I reboot my OS, I often find that the execution attribute of
> this script lost automatically.
>
> Any hints on this issue?

Does your OS use msec on a chron job, that checks security status?

It can change ownership and permissions on a file, in accordance with the
directory it is in and other criteria.

Cheers!

jim b.


--
UNIX is not user-unfriendly; it merely
expects users to be computer-friendly.