Apache CGI lp: Permission Denied


1

Przeniosłem skrypt CGI Perla ze starego systemu Linux RedHat na nowszy system Linux CentOS i jestem pewien system komendy już nie działają.

na przykład system("ls -l filename"); działa OK, ale system("lp -d printer filename"); zwraca lp: Permission denied.

Sprawdziłem uprawnienia do katalogów i plików, mogę używać tego samego skryptu CGI sudo -u apache scriptname a potem kłopotliwe system polecenia działają dobrze.

O ile wiem, httpd Apache nie jest chrootowany i nie ma w nim nic oczywistego httpd.conf (który jest prawie tak zainstalowany).

Więc dlaczego mam lp: Permission Denied?


Oto skrypt testowy

#!/usr/bin/perl
use strict;
use warnings;
#use CGI::Carp qw(fatalsToBrowser);

BEGIN {
  open (STDERR, '>&STDOUT') || die "cant merge STDERR $!\n";
  $|=1;
}

print "Content-Type: text/plain\n\n";
print "TEST\n\n";
psys('id');
psys('which lp');
psys('ls -l /tmp/po-list.19025.ps');
psys('ls -ld /usr /usr/bin /usr/bin/lp');
psys('ls -l /etc/alternatives/print-lp');
psys('ls -l /usr/bin/lp.cups');
psys('lp -d laser1 /tmp/po-list.19025.ps');
psys('ls /home | wc -l');
print "Finished\n";

sub psys {
  my $command = shift;
  print "# $command\n";
  system($command);
  print "\n";
}

Oto, co otrzymuje przeglądarka

TEST

# id
uid=48(apache) gid=48(apache) groups=48(apache) context=user_u:system_r:httpd_sys_script_t:s0

# which lp
/usr/bin/lp

# ls -l /tmp/po-list.19025.ps
-rw-r--r-- 1 apache apache 2309 Aug 30 15:59 /tmp/po-list.19025.ps

# ls -ld /usr /usr/bin /usr/bin/lp
drwxr-xr-x 15 root root  4096 Sep 22  2011 /usr
drwxr-xr-x  2 root root 36864 Aug 30 12:06 /usr/bin
lrwxrwxrwx  1 root root    26 Mar 18  2011 /usr/bin/lp -> /etc/alternatives/print-lp

# ls -l /etc/alternatives/print-lp
lrwxrwxrwx 1 root root 16 Sep 22  2011 /etc/alternatives/print-lp -> /usr/bin/lp.cups

# ls -l /usr/bin/lp.cups
-rwxr-xr-x 1 root root 18792 Mar 30  2011 /usr/bin/lp.cups

# lp -d laser1 /tmp/po-list.19025.ps
lp: Permission denied

# ls /home | wc -l
ls: /home: Permission denied
0

Finished

Nie mogę odtworzyć tego w moim systemie za pomocą skryptu, który podałeś. Używa pełnej ścieżki do lp praca? ls jest w /bin/ i lp jest w /usr/bin. Być może użytkownik apache nie ma /usr/bin na swojej drodze?
terdon

@terdon: Ta sama odpowiedź na /usr/bin/lp ... !
RedGrittyBrick

Odpowiedzi:


3

selinux!

Okazuje się, że miałem selinux zainstalowany i włączony. Przy odrobinie konfiguracji problem zniknął

Wskazówki były

  • sznurek context=user_u:system_r:httpd_sys_script_t:s0 na wyjściu id
  • obecność selinux folder w /

Znalazłem przepis na rozwiązanie w http://www.thedumbterminal.co.uk/php/knowledgebase/article/131 co spowodowało, że sprawdziłem plik audit.log - zauważyłem tam comm="lp" i denied (tj. odmowa komendy lp)

Krwawe szczegóły następują na wypadek, gdyby pomagały komukolwiek innemu

# grep 'comm="lp' /var/log/audit/audit.log | tail -n 2
type=AVC msg=audit(1346348949.002:30060): avc:  denied  { name_connect } for  pid=20130 comm="lp" dest=631 scontext=user_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:ipp_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1346348949.002:30060): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=2b0a50c0b108 a2=10 a3=7ffffa3aeba4 items=0 ppid=20123 pid=20130 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="lp" exe="/usr/bin/lp.cups" subj=user_u:system_r:httpd_sys_script_t:s0 key=(null)


# grep 'comm="lp' /var/log/audit/audit.log | tail -n 3 | audit2allow


#============= httpd_sys_script_t ==============
allow httpd_sys_script_t ipp_port_t:tcp_socket name_connect;


# grep 'comm="lp' /var/log/audit/audit.log | tail -n 3 | audit2allow -M secommands
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i secommands.pp


# ls secom*
secommands.pp  secommands.te


# /usr/sbin/semodule -i secommands.pp


# wget -O - http://localhost/cgi-bin/t4.pl
--2012-08-30 19:05:09--  http://localhost/cgi-bin/t4.pl
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: `STDOUT'

    [<=>                                    ] 0           --.-K/s              TEST


# /usr/bin/lp -d laser1 /tmp/po-list.19025.ps
request id is laser1-23 (1 file(s))

# ls /home | wc -l
ls: /home: Permission denied
0

Finished
    [ <=>                                   ] 2,034       --.-K/s   in 0.03s

2012-08-30 19:05:09 (56.9 KB/s) - `-' saved [2034]

Polecenie lp działa, nie martwię się, że nie będę w stanie ls on / home - to funkcja bezpieczeństwa, którą lubię.


Dobrze zauważony :)
terdon
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.