Problem z uruchomieniem skryptu -> uprawnienia/sudo?

[Pawel]

Chcialem uruchomic skrypt i wywala mi permission denied. Macie pomysl,
co robie nie tak?

Komenda uruchomiona z poziomu roota.
sudo -u www-data /scripts/nextcloud_cron.sh
sudo: unable to execute /scripts/nextcloud_cron.sh: Permission denied


drwxr-xr-x 8 pawel pawel 4096 cze 15 00:39 ./
drwxr-xr-x 8 pawel pawel 4096 sie 9 2020 ../
-rw-rw-rwx 1 pawel pawel 303 cze 15 00:39 nextcloud_cron.sh*


Docelowo ten skrypt ma byc uruchamiany z poziomu usera www-data(z
crona), wiec chcialem sprawdzic, czy sie uruchomi uzywajac sudo.
Czy other ustawione na rwx nie powinno uruchomic tego?

[Kamil Jońca]

Hm.
%ll ~/tmp/dpa.sh
-rw------- 1 kjonca kjonca 22 Jun 15 09:01 /home/kjonca/tmp/dpa.sh
%cat ~/tmp/dpa.sh
#!/bin/sh
echo dziala
%~/tmp/dpa.sh
zsh: permission denied: /home/kjonca/tmp/dpa.sh
%chmod o=rx /home/kjonca/tmp/dpa.sh
%ll ~/tmp/dpa.sh
-rw----r-x 1 kjonca kjonca 22 Jun 15 09:01 /home/kjonca/tmp/dpa.sh
%~/tmp/dpa.sh
zsh: permission denied: /home/kjonca/tmp/dpa.sh
%chmod u=rx /home/kjonca/tmp/dpa.sh
%~/tmp/dpa.sh
dziala
ll ~/tmp/dpa.sh
-r-x---r-x 1 kjonca kjonca 22 Jun 15 09:01 /home/kjonca/tmp/dpa.sh

W sumie ciekawe.
KJ

PS. mam wrażenie, że wykonanie podobnego testu zajęłoby Ci mniej czasu
niż napisanie na news. :/

--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

[K]

a www-data jest w sudoers?

[marrgol]

Żeby móc uruchomić, trzeba najpierw móc odczytać -- obstawiam,
że user www-data nie ma uprawnień (rx) do /scripts.


--
mrg

[Pawel]

W dniu 15.06.2022 o 14:05, marrgol pisze:

Przeciez other ma uprawnienia read i execute

drwxr-xr-x 8 pawel pawel 4096 cze 15 00:39 ./
drwxr-xr-x 8 pawel pawel 4096 sie 9 2020 ../

A zeby bylo ciekawiej, taka komenda dziala
sudo -u www-data crontab -l

[marrgol]

No tak, jakoś nie zwróciłem uwagi. :-)

> A zeby bylo ciekawiej, taka komenda dziala
> sudo -u www-data crontab -l

A taka?

$ sudo -u www-data bash -s < /scripts/nextcloud_cron.sh

Może filesystem jest zamontowany z opcją 'noexec'?


--
mrg

[Pawel]

W dniu 15.06.2022 o 16:03, marrgol pisze:

> A taka?
>
> $ sudo -u www-data bash -s < /scripts/nextcloud_cron.sh

Ok, takie cos dziala, ale czemu to dziala, a zwykle wywolanie skryptu nie?

[Kamil Jońca]

Bo tu system woła basha (który czyta wejście) a nie Twój skrypt.
KJ


PS. Czy wszyscy mają mnie w KF? Wysłałem wcześniej posta z w którym
widać, ze problem (IMO) jest w tym, że user nie ma "x".
KJ

--
http://wolnelektury.pl/wesprzyj/teraz/

[Pawel]

W dniu 15.06.2022 o 22:19, Kamil Jońca pisze:

> Pawel <ppf9@USUN_TOpoczta.fm> writes:
>
>> W dniu 15.06.2022 o 16:03, marrgol pisze:
>>
>>> A taka?
>>> $ sudo -u www-data bash -s < /scripts/nextcloud_cron.sh
>> Ok, takie cos dziala, ale czemu to dziala, a zwykle wywolanie skryptu nie?
>>
>
> Bo tu system woła basha (który czyta wejście) a nie Twój skrypt.
> KJ
>

Ok, to w taki razie, czemu jak probuje uruchomic "crontab -l", to takie
cos dziala, a jak probuje uruchomic moj skrypt, to juz nie.

>
> PS. Czy wszyscy mają mnie w KF? Wysłałem wcześniej posta z w którym
> widać, ze problem (IMO) jest w tym, że user nie ma "x".
> KJ
>

ls -al /scripts/nextcloud_cron.sh
-rwxrwxrwx 1 pawel pawel 303 cze 15 00:39 /scripts/nextcloud_cron.sh*

[Kamil Jońca]

Pawel <ppf9@USUN_TOpoczta.fm> writes:

> W dniu 15.06.2022 o 22:19, Kamil Jońca pisze:
>> Pawel <ppf9@USUN_TOpoczta.fm> writes:
>>
>>> W dniu 15.06.2022 o 16:03, marrgol pisze:
>>>
>>>> A taka?
>>>> $ sudo -u www-data bash -s < /scripts/nextcloud_cron.sh
>>> Ok, takie cos dziala, ale czemu to dziala, a zwykle wywolanie skryptu nie?
>>>
>> Bo tu system woła basha (który czyta wejście) a nie Twój skrypt.
>> KJ
>>
> Ok, to w taki razie, czemu jak probuje uruchomic "crontab -l", to
> takie cos dziala, a jak probuje uruchomic moj skrypt, to juz nie.

Nie wiem.
"crontab" ma pewnie "x" wszędzie tam gdzie trzeba (a może nawet suid)
jest na odpowiednim systemie plików itp. Twojemu skryptowi czegoś
takiego brakuje.

>> PS. Czy wszyscy mają mnie w KF? Wysłałem wcześniej posta z w którym
>> widać, ze problem (IMO) jest w tym, że user nie ma "x".
>> KJ
>>
> ls -al /scripts/nextcloud_cron.sh
> -rwxrwxrwx 1 pawel pawel 303 cze 15 00:39 /scripts/nextcloud_cron.sh*
> sudo -u www-data /scripts/nextcloud_cron.sh
> sudo: unable to execute /scripts/nextcloud_cron.sh: Permission denied
>

Czyli to raczej nie jest probelm z uprawinieniami skryptu jako takiego.
1. jaka jest pierwsza linijka tego skryptu.
2. jak wyglądają uprawnienia katalogów.
3. czy ten skrypt nie robi sudo gdzieś
4. wspomniane noexec (ale wtedy root też by chba nie mógł?)
KJ
--
http://wolnelektury.pl/wesprzyj/teraz/

[Pawel]

W dniu 15.06.2022 o 22:48, Kamil Jońca pisze:

>>> PS. Czy wszyscy mają mnie w KF? Wysłałem wcześniej posta z w którym
>>> widać, ze problem (IMO) jest w tym, że user nie ma "x".
>>> KJ
>>>
>> ls -al /scripts/nextcloud_cron.sh
>> -rwxrwxrwx 1 pawel pawel 303 cze 15 00:39 /scripts/nextcloud_cron.sh*
>> sudo -u www-data /scripts/nextcloud_cron.sh
>> sudo: unable to execute /scripts/nextcloud_cron.sh: Permission denied
>>
> Czyli to raczej nie jest probelm z uprawinieniami skryptu jako takiego.
> 1. jaka jest pierwsza linijka tego skryptu.

To jest caly skrypt

====================
#!/bin/bash

source variables.sh

if test -f "$backup_lock_file_path"; then
echo "Backup in progress."
else
echo "Backup is not running."
php -f /nextcloud/cron.php
fi
====================
W pliku variables.sh sa tylko te dwie linijki

#!/bin/bash
backup_lock_file_path='/var/run/backup_in_progress.lock'

ale to nie ma wplywu, bo probowalem takze zakomentowac ta linie source i
wrzucilem ta zmienna bezposrednio do pliku nextcloud_cron.sh

ls dla pliku variables.sh
-rw-rw-r-- 1 pawel pawel 70 cze 15 00:39 /scripts/variables.sh

> 2. jak wyglądają uprawnienia katalogów.

Ktore katalogi? Dalem w jednym z postow, wynik ls dla katalogu scripts i
jeden wyzej

> 3. czy ten skrypt nie robi sudo gdzieś

Jak wyzej.

> 4. wspomniane noexec (ale wtedy root też by chba nie mógł?)

Skrypt jest na partycji root
/dev/nvme0n1p2 on / type ext4 (rw,nodiratime,relatime)
Partycja home ma takie same uprawnienia.

[marrgol]

On 16/06/2022 at 02.53, Pawel wrote:
>> 2. jak wyglądają uprawnienia katalogów.
> Ktore katalogi? Dalem w jednym z postow, wynik ls dla katalogu scripts i
> jeden wyzej

Pokaż wynik:

$ stat -c "%n, %a, %U, %G, %F, %m" / /scripts /scripts/nextcloud_cron.sh

Używasz ACL-i? SELinuxa? AppArmora? Próbowałeś skopiować/przenieść
(na próbę) nextcloud_cron.sh do /usr/bin ?

>> 3. czy ten skrypt nie robi sudo gdzieś
> Jak wyzej.

Skrypt nie robi, ale może coś w konfiguracji sudo jest nie tak? Pokaż:

$ grep '^[^#\n].*' /etc/sudoers /etc/sudoers.d/*

>> 4. wspomniane noexec (ale wtedy root też by chba nie mógł?)

Wygląda na to, że nie noexec, ale czy root może, tego nie wiemy. :-)

$ sudo /scripts/nextcloud_cron.sh

działa?


--
mrg

[Pawel]

W dniu 16.06.2022 o 15:06, marrgol pisze:

> On 16/06/2022 at 02.53, Pawel wrote:

Widze, ze to troche powazniejszy problem, wiec troche uscisle informacje
ktore przekazalem. Skrypt znajduje sie dokladniej w lokalizacji
/MOJE/scripts/nextcloud_cron.sh
Staram sie ograniczac ilosc informacji, ktore na poczatku uwazalem za
zbedne, wiec okroilem sciezke.

>>> 2. jak wyglądają uprawnienia katalogów.
>> Ktore katalogi? Dalem w jednym z postow, wynik ls dla katalogu scripts i
>> jeden wyzej
>
> Pokaż wynik:
>
> $ stat -c "%n, %a, %U, %G, %F, %m" / /scripts /scripts/nextcloud_cron.sh
>

stat -c "%n, %a, %U, %G, %F, %m" / /MOJE /MOJE/scripts
/MOJE/scripts/nextcloud_cron.sh
/, 755, root, root, directory, /
/MOJE, 755, root, root, directory, /
/MOJE/scripts, 777, root, root, symbolic link, /
/MOJE/scripts/nextcloud_cron.sh, 544, www-data, www-data, regular file, /

> Używasz ACL-i?  SELinuxa?  AppArmora?  Próbowałeś skopiować/przenieść
> (na próbę) nextcloud_cron.sh do /usr/bin ?
>

Nic mi o tym niewiadomo. Jesli Ubuntu server nic nie ustawia za mnie, to
zadne tego typu mechanizmy nie powinny byc wlaczone.

>
>>> 3. czy ten skrypt nie robi sudo gdzieś
>> Jak wyzej.
>
> Skrypt nie robi, ale może coś w konfiguracji sudo jest nie tak?  Pokaż:
>
> $ grep '^[^#\n].*' /etc/sudoers /etc/sudoers.d/*
>

/etc/sudoers:Defaults env_reset
/etc/sudoers:Defaults mail_badpass
/etc/sudoers:Defaults
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
/etc/sudoers:root ALL=(ALL:ALL) ALL
/etc/sudoers:%admin ALL=(ALL) ALL
/etc/sudoers:%sudo ALL=(ALL:ALL) ALL

Nie za duzo tych ALL-i. Czy takie ustawienia sa bezpieczne?

>
>>> 4. wspomniane noexec (ale wtedy root też by chba nie mógł?)
>
> Wygląda na to, że nie noexec, ale czy root może, tego nie wiemy. :-)
>
> $ sudo /scripts/nextcloud_cron.sh
>
> działa?
>

Udalo mi sie dojsc, gdzie lezy problem. Problemem najwyrazniej jest
katalog w ktorym zznajduje sie ten skrypt. Jak przerzucileem ten skrypt
do '/', to wszystko chodzi, zaarowno jak probuje recznie to uruchomic,
jak i z poziomu crontaba.
Cos rzucilo mi sie w oczy, ze symlinki w crontabie nie jest dobrym
rozwiazaniem, ale nie wczytywalem sie jeszcze, bo juz pozno. Jutro sie
temu przyjrze, chyba, ze wy cos zaproponujecie wczesniej.

[marrgol]

On 17/06/2022 at 03.05, Pawel wrote:
> Widze, ze to troche powazniejszy problem, wiec troche uscisle informacje
> ktore przekazalem. Skrypt znajduje sie dokladniej w lokalizacji
> /MOJE/scripts/nextcloud_cron.sh
> Staram sie ograniczac ilosc informacji, ktore na poczatku uwazalem za
> zbedne, wiec okroilem sciezke.

Noszsz… jak typowy klient dowolnego serwisu -- skoro nie wiesz,
w czym problem, to jak oceniasz, które informacje są zbędne? :-)

Tutaj istotną informacją nie jest okrojona ścieżka, a to, że 'scripts'
jest linkiem. Linkowanie nie zmienia uprawnień, obowiązują te do
linkowanego pliku lub katalogu. Jak ustawisz uprawnienie 'x' dla
www-data dla wszystkich katalogów na _rzeczywistej_ ścieżce do
nextcloud_cron.sh to powinno być ok.

>> $ grep '^[^#\n].*' /etc/sudoers /etc/sudoers.d/*
>>
> /etc/sudoers:Defaults env_reset
> /etc/sudoers:Defaults mail_badpass
> /etc/sudoers:Defaults
> secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
> /etc/sudoers:root ALL=(ALL:ALL) ALL
> /etc/sudoers:%admin ALL=(ALL) ALL
> /etc/sudoers:%sudo ALL=(ALL:ALL) ALL
>
> Nie za duzo tych ALL-i. Czy takie ustawienia sa bezpieczne?

Są.


--
mrg

[Pawel]

W dniu 17.06.2022 o 13:53, marrgol pisze:

>> Staram sie ograniczac ilosc informacji, ktore na poczatku uwazalem za
>> zbedne, wiec okroilem sciezke.
>
> Noszsz… jak typowy klient dowolnego serwisu -- skoro nie wiesz,
> w czym problem, to jak oceniasz, które informacje są zbędne? :-)
>

Trochę już siedzę w linuksie, więc obstawiałem crona, albo sudo.

> Tutaj istotną informacją nie jest okrojona ścieżka, a to, że 'scripts'
> jest linkiem.  Linkowanie nie zmienia uprawnień, obowiązują te do
> linkowanego pliku lub katalogu.  Jak ustawisz uprawnienie 'x' dla
> www-data dla wszystkich katalogów na _rzeczywistej_ ścieżce do
> nextcloud_cron.sh to powinno być ok.

Dzieki. Miales racje. Jeden z podkatalogow na sciezce mial uprawnienia
770. Po zmianie na 775 wszystko poszlo.