Witam,

Tworze panel administracyjny linuxa (webowy). I napotkałem się z pewnym problemem.
Przez PHP uruchamiam program napisany w c++ i chciał bym przekazac zmienna z PHP do tego programu i w drogą strone.
Wytłumaczę na przykładzie

PhP uruchamia program C++ który w powłoce shellowej wykonuje polecenie tworzące użytkownika "adduser". Musze teraz po przez php przekazać do c++ login tego użytkownika. Gdy już to się zrobi c++ powinien wysłać odpowiedz serwera z żądaniem hasła, php wysyła hasło.

To co już napisałem

PHP:

[PHP] pobierz, plaintext 
<?php
shell_exec('cd /home/buker/programy && ./adduser');
?>
[PHP] pobierz, plaintext 

Program C++:

[PHP] pobierz, plaintext 
#include <stdio.h>
#include <stdlib.h>
#include <string>
int main(){
 
 
system("adduser test");
};
 
 
[PHP] pobierz, plaintext 

Proponowałbym od razu przekazać login i hasło (pochodzące np. z formularza). Programowi napisanemu w C++ można przekazać parametry:
Skrypt PHP:

[PHP] pobierz, plaintext 
<?php
$command = 'cd /home/buker/programy && ./adduser '.$username.' '.$password;
$result = shell_exec($command);
?>
[PHP] pobierz, plaintext 

Nie wiem tylko dlaczego w tworzeniu użytkownika ma pośredniczyć program w C++, tym bardziej, że wywołuje on komendę powłoki shell. Przecież to bez sensu, bo równie dobrze można to zrobić w PHP.

Ponieważ php nie moze wykonca polecenia z prawami roota co jest konieczne do wykonywania niektorych polecen. To rozwiazanie jest dobre jesli chodzi o przekazanie loginu. z haslem jest gorzej. Bo system odpowie zapytaniem o haslo a nie odrazu przyjmie

Hmm, dalej nie rozumiem skoro przekażesz od razu, to wykonujesz adduser a system pyta a program odpowiada wcześniej podanym hasłem, gdzie problem?

Dlatego nie komenda nie wyglada adduser login, a nie adduser login haslo


Pokazuje jak wyglada procedura.

- adduser login
- podajesz haslo
- potwierdzasz haslo

PHP: Cześć mam dla Ciebie login i hasło
C++: Ok, przekaż mi jako parametry przy uruchomieniu
PHP: Przekazuję parametry do programu

C++: Cześć system, chciałbym dodać usera o nicku: test
System: Nie ma problemu, podaj hasło:
C++: Czekaj wyciągnę je z parametru, który dostałem od PHP gdy mnie uruchamiał
C++: Przekazuję
System: Potwierdź
C++: Potwierdzam
System: Dzięki
C++: Nie ma sprawy

C++: User dodany
PHP: Dzięki za info


Tak w formie żartu, może teraz zrozumiesz o co mi chodzi.

OK już rozumiem . Tylko teraz mam następny problem.

Sam komunikat mówi wprost... Zrąbałeś kod w C++, a że go nie znamy to o czym my teraz mamy rozmawiać? Są tutaj ludzie w C++ piszący więc zapewne błąd też się wyłapie

To jest ten sam kod co kilka postów wyżej. Chciałem go sprawdzić

Konkatenować plusem to Ty możesz stringi, a nie tablice znaków*. Jak się upierasz na chary, to sobie znajdz funkcje łączącą tablice znaków. strcat chyba.




* - chyba, że o czymś nie wiem

No cóż, dawno nie siedziałem przy C++ i mógł się wkraść błąd.

No i jest lipa. Jak wykonam program.

To jest fragment z działania programu:



I tak prosi o hasła. Jak wpisze wszystko tak żeby poszło dalej dopiero się wywołuje funkcja system z hasłem

Nie wiem jak to rozwiązać zgodnie z tym, co powiedzieli poprzednicy, ale wiem, że:

1. Zgodnie z dokumentacja adduser może przyjąć hasło jako argument (Google: man adduser).
2. Adduser jest interaktywną nakładką na nieinteraktywny useradd (Google: man useradd).

Po cholere to wywoływać z c++ ?

To nie prościej to posłąć wprost jako komendę do shella wprost z poziomu php? Zamiast walić pośrednika w postaci programu w C++ od razu wywołaj polecenie, o ile masz uprawnienia. A jeśli nie to chyba prościej będzie zamiast kodu w C++ napisać skrypt bash'owy.

Nie ma sensu tego nawet z basha wywołać, przecież nie uruchomisz programu z php czy to w c++ czy w pythonie czy w czym kolwiek innym niż z uprawnieniami które posiada php. Tudzież apache.

Niby tak, ale...
1. Na linuksach (i innych unixach) apache nie chodzi z uid=0, więc wykonanie skryptu się nie powiedzie, bo nie-root nie da rady dodać usera do systemu. Apache jest URUCHAMIANE przez administratora (by dopiąć się do portu <1024) i "zrzuca" swoje prawa na uid różny od zera. Nazwa usera (i zarazem nazwa grupy) to najczęściej "apache", "httpd", "www" czy "www-data". Zwykły, nieuprzywilejowany użytkownik.
2. binarka jest "niby" wygodniejsza, można dać jej SUID, czyli "sticky bit UID" - prawa uniksowe 4750, ustawić właściciela na roota, a grupę na tę grupę, do której należy Apache (np. "www"), i się wykona z prawami roota. Czterocyfrowy chmod: pierwsza cyfra "4" mówi, że program wykonuje się z prawami tego użytkownika, który jest właścicielem pliku (tu: root). A reszta klasycznie: pełne prawa dla właściciela (którym jest root), prawa "rx" dla członków grupy "www" (czyli tej grupy, której członkiem jest user, którego prawa ma Apache i żadne prawa dla innych (w samym systemie też bywają "źli ludzie").
3. Jeśli Apache jest w środowicku chrootowanym (chroot/jail), to nawet suid nie pomoże - w głównym systemie nie zrobimy nic.

Ma to wady:
- napisanie własnego programu przez niefachowca to zawsze spora szansa na zrobienie dziury, a jak jeszcze "źli ludzie" się zwiedzą, to będzie nieciekawie
Swoją drogą... mając UID=0 (czyli prawa roota) jestem w stanie trzema komendami echo (i jedną "mkdir") dodać usera do systemu i nadac mu grupę, i nie ma w tym żadnej filozofii, w pierwszych uniksach taka była JEDYNA metoda na dodanie nowego usera do systemu - więc napisanie skryptu może odbyć się "bardzo szybko"

Proponuję metodę pośrednią:
- Apache zapisuje sobie dane userów w pliku w katalogu serwera WWW
- z crona uruchamiasz zwykłego skrypta, który już operuje z prawami dowolnego usera w systemie (czyli może także działać z prawami roota) i założy Ci tego usera... Ale to oczywiście jest wada porównywalna z binarką wystawioną w drzewie serwera WWW.

Ma to zalety:
- zadziała w środowisku chrootowanym
- możesz sobie dowolnie posprawdzać wszystkie dane "już na spokojnie".

...ale i wady:
Nie jesteś w stanie "online" poinformować usera o fakcie założenia konta, ani tym bardziej zwrócić mu informacji, że np. login jest już zajęty. Przetwarzasz plik w cronie, czyli z granulacją conajmniej minutową.

P.S.
można jeszcze korzystać z sudo, ale to też gimnastyka...

Ten post nic nie wnosi do tematu. Nawet nie przeczytałeś co jest napisane wcześniej.




Da się z uprawnieniami SUID/SGID ale tylko programy wykonywalne. Czyli skrypty bash/perl odpadaja wiec zostaje program w c/c++ .



Sudo już próbowałem i w żaden sposób to nie działa www-data(apache) nawet dodany do sudo bez konieczności wpisywania hasła (NOPASSWORD) i tak chce wyświetlić prośbę o hasło czego nie może zrobić .


Natchnęło mnie twoje stwierdzenie :

Program by poklei wykonywał polecenia useradd groupadd i mkdir z odpowiednimi parametrami i wtedy by nie było problemu hasła. Tak mi się zdaje... Jutro napisze to i się pochwale co wyszlo

http://www.suphp.org/Home.html i po ptokach.

No i cojack pozamiatał.

Ja dodam jeszcze tylko dwie inne metody:

1. sudo
2. Konfiguracja demona ssh pozwalająca na logowanie się na localhost przez localhost do konta super użyszkodnika. Można w tym celu na przykład utworzyć dodatkowy demon ssh działający na innym porcie i poblokować dostęp w iptables z innych hostów.