i=open("./test.test", O_WRONLY | O_CREAT, 0666) Berechtigungen werden nicht übernommen

[Gibts N. (schneeblau)]

Hallo, bin noch relativ neu unter Linux.


Ich starte meine Programmierumgebung per sudo. Dies ist für einige 
Funktionen in meinem C Programm notwendig.


Ich erstelle außerdem eine Datei mit

i=open("./test.test", O_WRONLY | O_CREAT, 0666)

Wenn ich die Datei dann per ls -l prüfe, kommen aber folgende 
Berechtigungen raus:
-rw-r--r-- obwohl es ja wohl -rw-rw-rw- heißen müsste oder? Weiß jemand 
woran das liegen könnte?

[Timmo H. (masterfx)]

wie ist du umask von deinem Prozess? 022?

[Gibts N. (schneeblau)]

Das wars gewesen, danke für das richtige Stichwort.

[Malte S. (maltest)]

Gibts Ne schrieb:
> Ich starte meine Programmierumgebung per sudo. Dies ist für einige
> Funktionen in meinem C Programm notwendig.

Besser wäre es, dann nur dieses Programm per sudo zu starten und nicht 
mit root-Rechten zu entwickeln. Und dann bleibt noch die Frage, für was 
genau du die Reche brauchst und ob sich da nicht ein präziseres Werkzeug 
für finden lässt als der Vorschlaghammer (root).
Zumal im Zusammenhang mit 0666er-Berechtigungen. World writable ist in 
den aller seltensten Fällen wirklich das, was du willst.

[Gibts N. (schneeblau)]

Ist nur eine log Datei, von mir aus kann da jeder reingucken bzw. damit 
machen was er will:) Das x hab ich nur weggelassen, weil halt kein 
Programm drinne steht.

Ich entwickelte erst unter Geany, dort war es möglich Geany normal zu 
starten und nur dem geschriebenen Programm das sudo mitzugeben. In 
Codeblocks hatte ich gelesen bzw. ausprobiert, dass das nicht so einfach 
geht. Als Lösung bot sich an, Codeblocks per sudo zu starten, da so die 
Berechtigungen auch für das selbst programmierte Programm gelten.

Ich nutze eine Library, die zwingend root Rechte braucht, weil sie in 
der Hardware rumwerkelt:)

[Jörg W. (dl8dtl) (Moderator)]

Gibts Ne schrieb:
> Ich nutze eine Library, die zwingend root Rechte braucht, weil sie in
> der Hardware rumwerkelt:)

Glaub' ich dir nicht. Der Hardwarezugriff erfolgt über Treiber, und
die Schnittstelle der Treiber nach oben ist ein device node (typisch
unter /dev gelegen). Die Zugriffsrechte dieses device nodes sind
normalerweise das Mittel zum Steuern, wer da was darf.

Ich weiß, manchmal limitieren die Treiber auch selbst noch und
erwarten, dass sie mit UID == 0 arbeiten, aber das könnte man dann
durchaus auch im Treiber ändern (zumindest für die Zeitdauer der
Entwicklungsarbeiten), ohne dass die Gesamtsicherheit des Systems
im Vergleich zu deiner derzeitigen Variante (relativ komplexe
Entwicklungsumgebung unter UID == 0 laufen lassen) schlechter wäre.

[Peter II (Gast)]

Jörg Wunsch schrieb:
> ohne dass die Gesamtsicherheit des Systems
> im Vergleich zu deiner derzeitigen Variante (relativ komplexe
> Entwicklungsumgebung unter UID == 0 laufen lassen) schlechter wäre.

muss man denn wirklich alles Vorgeben? Warum sollte mit Linux 
vorschreiben wie man zu arbeiten hat? Wenn ich es einfacher finde als 
root zu arbeiten dann mache ich es. Ich fahre auch mal ohne Helm rad - 
kann nicht einfach jeder für sich entscheiden wir er arbeiten will?

Immer diese vorgaben, als ob leute selber keine Entscheidungen für sich 
mehr treffen können.

Braucht man nicht auch root rechte um einen Port < 1024 zu öffnen?

Ich arbeite selber auf meine Raspi nur als root, es macht überhaut keine 
sinn sich selber stolpersteine in den weg zu legen.

[Gibts N. (schneeblau)]

Eben, ich nutze das Ganze auch auf einem Raspberry Pi.


Die Bibliothek bcm2835.h benötigt halt root Rechte, um auf /dev/mem 
zugreifen zu können.

Damit ist ein sudo der einfachste Weg.

[Jörg W. (dl8dtl) (Moderator)]

Gibts Ne schrieb:
> um auf /dev/mem zugreifen zu können

Damit brauchst du dir nur /dev/mem zugreifbar zu machen, fert'sch.

[Nils S. (kruemeltee)]

chmod und/oder gpasswd sind deine Freunde in dem Fall.

[Malte S. (maltest)]

Peter II schrieb:
> Braucht man nicht auch root rechte um einen Port < 1024 zu öffnen?

Keine vollen root-Rechte, nur die CAP_NET_BIND_SERVICE-Capability. Oder 
einen priviligierten Prozess (systemd oder inetd/xinetd), der dir den 
Port öffnet und den fd rüberreicht.

[Nils S. (kruemeltee)]

Malte S. schrieb:
> Peter II schrieb:
>> Braucht man nicht auch root rechte um einen Port < 1024 zu öffnen?
>
> Keine vollen root-Rechte, nur die CAP_NET_BIND_SERVICE-Capability. Oder
> einen priviligierten Prozess (systemd oder inetd/xinetd), der dir den
> Port öffnet und den fd rüberreicht.

systemd braucht niemand !


;)

[Malte S. (maltest)]

Deshalb schrieb ich zur Vermeidung von Glaubenskriegen "oder 
inetd/xinetd" ;)

[Peter II (Gast)]

Jörg Wunsch schrieb:
> Damit brauchst du dir nur /dev/mem zugreifbar zu machen, fert'sch.

wenn du dort die Rechte änderst, dann kannst du auch gleiche allen 
Prozessen root rechte geben.

[Nils S. (kruemeltee)]

Peter II schrieb:
> wenn du dort die Rechte änderst, dann kannst du auch gleiche allen
> Prozessen root rechte geben.

Brauchst du doch nicht. Du lässt den Prozess als User laufen, der kmem 
Rechte hat und nur diesen einen Prozess ausführt.

//edit:

Schlechtes Desgin ist es trotzdem, auf kmem zugreifen tut man eigtl. 
nicht.