[SOLVED] Failed miserably to execute bash script via PATH variable after FS migration.

kopatops · 08-18-2010, 06:02 AM

Quote:

Originally Posted by pingu

My thought was that you might have /home mounted with options/flags not allowing you to execute.
But then, it shouldn't work with "bash scriptfile" either?
I have never used this possibility myself, but maybe it's worth digging into?
It could be that different filesystems have different default options.

After copying ~/ back to the new sda2, all files/dirs had root ownership. I changed that recursively using chown.

I only assumed that the 'user' option in fstab would let me execute scripts, and, as you say I *can* execute them, but only by calling bash explicitly for that particular script.

I forgot to mention, my default shell is indeed bash:

Code:

[user@computer /]$ cat /etc/passwd |grep bash
root:x:0:0:root:/root:/bin/bash
user:x:1000:100:,,,:~/:/bin/bash
[user@computer /]$

i92guboj · 08-18-2010, 06:05 AM

Quote:

Originally Posted by kopatops

After copying ~/ back to the new sda2, all files/dirs had root ownership. I changed that recursively using chown.

I only assumed that the 'user' option in fstab would let me execute scripts, and, as you say I *can* execute them, but only by calling bash explicitly for that particular script.

Beware about the difference between "user" and "users". A lot of people get confused by that. Double check the mount man page.

kopatops · 08-18-2010, 06:10 AM

Quote:

Originally Posted by i92guboj

He should check the output from "mount" without arguments and make sure that neither of "noexec" and "users" are between the mount options ("users" implies "noexec" by default).

When you open a script doing "bash <filename>" there's virtually no difference between that and doing "oowrite my_file.doc". Bash will launch a new session and start parsing the file. You can quickly check by setting -x on any random script and then launching it with bash or sh.

Code:

[user@computer /]$ mount
proc on /proc type proc (rw,relatime)
sys on /sys type sysfs (rw,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=239727,mode=755)
/dev/disk/by-uuid/d39a9c41-fece-4837-9f5e-b32bdbe5131e on / type ext4 (rw,noatime,discard,commit=0)
none on /dev/pts type devpts (rw)
none on /dev/shm type tmpfs (rw)
tmpfs0 on /tmp type tmpfs (rw,noatime,mode=1777)
tmpfs1 on /var/cache/pacman type tmpfs (rw,noatime,mode=1777)
/dev/sda2 on /mnt/0 type xfs (rw,noexec,nosuid,nodev,noatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/loop0 on /mnt/2 type udf (ro)
gvfs-fuse-daemon on /mnt/0/STATIC/DIR/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=user)
[user@computer /]$

Oh... my... holy penguin! How could I have been so stupid?? x(

sda2 is indeed flagged with noexec. Can I fix this easily?

kopatops · 08-18-2010, 06:22 AM

Ok. Replacing 'user' with 'users' gave the same result as before, with 'users' and 'user' obviously both implying 'noexec'.

Removing that mount option gets me full r,w and x privileges on sda2. All is well. I guess a RTFM! is in order

Thank you all for your help.

pingu · 08-18-2010, 06:23 AM

Quote:

Originally Posted by i92guboj

When you open a script doing "bash <filename>" there's virtually no difference between that and doing "oowrite my_file.doc". Bash will launch a new session and start parsing the file. You can quickly check by setting -x on any random script and then launching it with bash or sh.

Exactly. But what happens is that with noexec on the filesystem, he can execute the script if he types "bash scriptfile"! Suddenly the "noexec" has no effect, is this really the case?? A bit too easy to bypass security settings I'd say!

i92guboj · 08-18-2010, 06:29 AM

Quote:

Originally Posted by pingu

Exactly. But what happens is that with noexec on the filesystem, he can execute the script if he types "bash scriptfile"! Suddenly the "noexec" has no effect, is this really the case?? A bit too easy to bypass security settings I'd say!

As I said above, in that case he's not running a file. In which regards the shell, he is just opening a plain text document with a parser that happens to be named "bash" instead of "oowriter" or "gimp". There's no real difference between "oowrite file.doc", "gimp file.jpg" or "bash file.sh".

kopatops · 08-18-2010, 06:34 AM

There is obviously a difference between

Code:

$ bash ~/bin/script

and

Code:

$ sudo ~/script

It would seem that root (sudo) doesn't execute the file but only reads it as text and gives it to bash. (?)
Although that sounds like nonsense. [EDIT: Actually it makes sense] I suppose root can always read the text file?

Code:

[user@computer /]$ ls -l ~/bin | grep wifil
-rwxr-xr-x 1 user users    1340 Aug 18 08:12 wifil
[user@computer /]$

[EDIT]OK..

you beat me to it. All seems clear now.