Plesk 8.6 upgrade errors - Plesk won't start

[Kalimari]

I have used pleskbackup all with success, but still create manual back-ups of individual site files/db/mail, archive them, ftp them locally & make notes of all PSA accounts/limits/settings just in case something unexpected happens and set-up cannot be recovered.

IMHO, caution is paramount when moving sites between different Plesk versions. Peace-of-mind costs very little compared to the nightmare of loosing anything/everything.

[scott]

agreed, safety in numbers here. I make a plesk backup, and an rsync copy of the box when I do a re-image.

[octet]

Thanks guys!

After not sleeping at all last night I successfully re-image the box with CentOS 5.2, Plesk 8.6 working smoothly now and ASL kernel finally works, unlike on the Fedora (1&1 box).

[root@titan ~]# cat /etc/issue
CentOS release 5.2 (Final)

[root@titan ~]# uname -a
Linux titan.serverpro.biz 2.6.25.4-4.art.x86_64 #1 SMP Wed Jun 4 15:07:26 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

Scott, is ASL preventing users with bash access to run scripts? For instance I need to run a radio server and it won't allow me to run it as that user:

[dreambox@titan gbox]$ ./gbox >/dev/null &
[1] 6498
[dreambox@titan gbox]$ bash: ./gbox: Permission denied

-rwxrwxrwx 1 dreambox dreambox 1006264 Mar 22 2005 gbox


Regards,
Adrian

[breun]

The ASL kernel blocks users from running binaries that are not owned by root. So, instead of change the file mode to 777 you have to change the owner to root.

[octet]

breun,

I've changed the the permissions to root.usergroup and chmod to 775 and it won't still let me run it:

Code: Select all

Sep 16 19:56:20 s15268655 kernel: grsec: From 82.132.136.195: denied untrusted exec of /home/dreambox/gbox/gbox by /bin/bash[sh:13876] uid/euid:10032/10032 gid/egid:10032/10032, parent /bin/bash[sh:5867] uid/euid:10032/10032 gid/egid:10032/10032
Sep 16 19:58:55 s15268655 kernel: grsec: From 82.132.136.201: denied untrusted exec of /home/dreambox/ccam/CCcam.x86 by /bin/bash[bash:13949] uid/euid:10032/10032 gid/egid:10032/10032, parent /bin/bash[bash:13932] uid/euid:10032/10032 gid/egid:10032/10032
Sep 16 19:59:21 s15268655 kernel: grsec: From 82.132.136.195: denied untrusted exec of /home/dreambox/gbox/gbox by /bin/bash[sh:13982] uid/euid:10032/10032 gid/egid:10032/10032, parent /bin/bash[sh:5867] uid/euid:10032/10032 gid/egid:10032/10032

Also in /var/logs/messages I get those:

Code: Select all

Sep 16 20:01:06 s15268655 kernel: PAX: execution attempt in: <anonymous mapping>, 00602000-00632000 00602000
Sep 16 20:01:06 s15268655 kernel: PAX: terminating task: /usr/libexec/paxtest/mprotheap(mprotheap):14320, uid/euid: 0/0, PC: 00000000006105e0, SP: 00007a26e4b3f7d8
Sep 16 20:01:06 s15268655 kernel: PAX: bytes at PC: c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Sep 16 20:01:06 s15268655 kernel: PAX: bytes at SP-8: 00007a26e4b3f8e0 00000000004009fa 0000000000000000 0000000000400bbc 000000004154e940 0000000000000000 00006cb82e105bc0 00006cb82d99b8b4 00000000004008f0 00007a26e4b3f8e8 0000000100000000 
Sep 16 20:01:06 s15268655 kernel: PAX: execution attempt in: /usr/libexec/paxtest/mprotshbss, 00601000-00602000 00001000
Sep 16 20:01:06 s15268655 kernel: PAX: terminating task: /usr/libexec/paxtest/mprotshbss(mprotshbss):14332, uid/euid: 0/0, PC: 0000000000601280, SP: 0000791fd6fc9938
Sep 16 20:01:06 s15268655 kernel: PAX: bytes at PC: c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Sep 16 20:01:06 s15268655 kernel: PAX: bytes at SP-8: 0000791fd6fc9a40 0000000000400a24 0000000000000000 0000000000400bcc 000000004142f940 0000000000000000 00007086e6814bc0 00007086e5ea78b4 0000000000400920 0000791fd6fc9a48 0000000100000000 
Sep 16 20:01:07 s15268655 kernel: PAX: execution attempt in: /usr/libexec/paxtest/mprotshdata, 00601000-00602000 00001000
Sep 16 20:01:07 s15268655 kernel: PAX: terminating task: /usr/libexec/paxtest/mprotshdata(mprotshdata):14343, uid/euid: 0/0, PC: 0000000000601290, SP: 00007974c60c5d28
Sep 16 20:01:07 s15268655 kernel: PAX: bytes at PC: c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Sep 16 20:01:07 s15268655 kernel: PAX: bytes at SP-8: 00007974c60c5e30 0000000000400a2d 0000000000000000 0000000000400bcc 00000000416b5940 0000000000000000 000072a37b767bc0 000072a37adfa8b4 0000000000400930 00007974c60c5e38 0000000100000000 
Sep 16 20:01:07 s15268655 kernel: PAX: execution attempt in: <anonymous mapping>, 7d7e680cc000-7d7e680e1000 7ffffffea000
Sep 16 20:01:07 s15268655 kernel: PAX: terminating task: /usr/libexec/paxtest/mprotstack(mprotstack):14353, uid/euid: 0/0, PC: 00007d7e680e035f, SP: 00007d7e680e0348
Sep 16 20:01:07 s15268655 kernel: PAX: bytes at PC: c3 00 00 00 00 00 00 00 00 bc 0a 40 00 00 00 00 00 40 a9 d0 
Sep 16 20:01:07 s15268655 kernel: PAX: bytes at SP-8: 00007d7e680e0460 0000000000400923 00007d7e680e0460 c300000000000000 0000000000000000 0000000000400abc 0000000041d0a940 0000000000000000 00006f19b3792bc0 00006f19b30288b4 0000000000400820 
Sep 16 20:01:10 s15268655 kernel: PAX: execution attempt in: /usr/libexec/paxtest/shlibtest2.so, 7b84704eb000-7b84704ed000 00000000
Sep 16 20:01:10 s15268655 kernel: PAX: terminating task: /usr/libexec/paxtest/shlibbss(shlibbss):14597, uid/euid: 0/0, PC: 00007b84704ec7e0, SP: 00007fdc02c721c8
Sep 16 20:01:10 s15268655 kernel: PAX: bytes at PC: c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Sep 16 20:01:10 s15268655 kernel: PAX: bytes at SP-8: 00007b8470b18000 0000000000400c99 00007fdc02c722e0 0000000000000000 0000000000000000 0000000000400e7c 00000000425b4940 0000000000000000 00007b8470b25bc0 00007b846fdb18b4 0000000000400b10 
Sep 16 20:01:10 s15268655 kernel: PAX: execution attempt in: /usr/libexec/paxtest/shlibtest2.so, 74011f3df000-74011f3e1000 00000000
Sep 16 20:01:10 s15268655 kernel: PAX: terminating task: /usr/libexec/paxtest/shlibdata(shlibdata):14608, uid/euid: 0/0, PC: 000074011f3df7c0, SP: 00007ea153f0d7c8
Sep 16 20:01:10 s15268655 kernel: PAX: bytes at PC: c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Sep 16 20:01:10 s15268655 kernel: PAX: bytes at SP-8: 000074011fa0c000 0000000000400c94 00007ea153f0d8e0 0000000000000000 0000000000000000 0000000000400e7c 000000004105d940 0000000000000000 000074011fa19bc0 000074011eca58b4 0000000000400b10 
Sep 16 20:01:10 s15268655 kernel: grsec: signal 11 sent to /usr/libexec/paxtest/writetext[writetext:14620] uid/euid:0/0 gid/egid:0/0, parent /usr/libexec/paxtest/writetext[writetext:14619] uid/euid:0/0 gid/egid:0/0

Is that normal?


Adrian

[breun]

TPE (Trusted Path Execution) prevents binaries that are not in root-owned non-world writable directories from running.

[octet]

What would that be in plain English?:shock:




Do I need to add the user to a different group? Or how should I chmod the files / directories?

Thank you,
Adrian

[breun]

The directory the binary is in should be owned by root (use chown root) and the directory should not be world-writable (use chmod o-w).

[octet]

Code: Select all

[dreambox@titan ~]$ pwd
/home/dreambox
[dreambox@titan ~]$ ll
total 4
drwxrwxr-x 2 root dreambox  101 Sep  8 18:42 ccam
[dreambox@titan ~]$ cd ccam/
[dreambox@titan ccam]$ ll
total 672
-rwxrwxr-x 1 root dreambox  19757 Sep 14 18:00 CCcam.cfg
-rwxrwxr-x 1 root dreambox 631176 Sep  8 13:14 CCcam.x86
[dreambox@titan ccam]$ ./CCcam.x86 -C /home/dreambox/ccam/CCcam.cfg &
[1] 16852
[dreambox@titan ccam]$ bash: ./CCcam.x86: Permission denied

[breun]

You could take this up with support@atomicorp.com, but I believe every directory in the path may need to be owned by root (/home/dreambox is probably owned by dreambox instead of root). I'd put the app in /opt/ccam or /usr/local/ccam myself.

[scott]

Yup, has to be owned by root, and group owned by root. Only writable by root, in root owned directories.