Re: uucico als login shell unter FreeBSD?
Von: Holger Weiss (holger@weiss.in-berlin.de) [Profil]
Datum: 12.02.2008 14:11
Message-ID: <fos5tm$9ui$1@news.weiss.in-berlin.de>
Newsgroup: de.comm.uucp
Datum: 12.02.2008 14:11
Message-ID: <fos5tm$9ui$1@news.weiss.in-berlin.de>
Newsgroup: de.comm.uucp
* Ignatios Souvatzis <u502sou@beverly.kleinbus.org> [2008-02-12 09:35 UTC]: > Michael Grimm wrote: > > Volker Englisch <envo@gmx.de> wrote: > >> $ uucp -r testfile.txt deinuucpname\!~ > >> > >> transferiert testfile.txt in Dein /var/spool/uucppublic, wenn der Pfad > >> nicht in der UUCP-Konfiguration "umgebogen" wurde. Wenn der Key nun > >> für den Owner uucp schreibbar ist und dieser Befehl über Deinen Peer > >> hereinkommend ausgeführt wird / werden darf... überlasse ich der > >> Phantasie des Lesers, was dann geschieht :-) > > > > Wenn ihm in der sys nur rnews und rmail zugestanden (commands) werden, > > dürfte er das doch gar nicht ausführen dürfen? Oder stehe ich auf'm > > Schlauch? Per uucp(1) koennen defaultmaessig trotzdem Dateien transferiert werden. In meiner Konfiguration habe ich: # Das Remote-System darf per uucp(1) nichts von uns abrufen oder bei uns # einwerfen. Ersteres laesst sich mit "send-request no" konfigurieren, # letzteres allerdings nicht mit "receive-request no", weil man uns # sonst auch keine rmail(1) oder rnews(1) via uux(1) senden koennte. # Daher stattdessen "remote-receive /does/not/exist". send-request no remote-send /does/not/exist # Wegen "send-request no" redundant. remote-receive /does/not/exist > Naja, das wirklich grausliche Szenario ist, was passiert, wenn > a!b!foo funktioniert. Scheint hier nicht der Fall zu sein, jedenfalls sagt unser Provider zu einem "uucp test.txt 'provider!odo!~'": | Your execution request failed because you are not permitted to forward files | to the system | odo Wie langweilig :-) Holger[ Auf dieses Posting antworten ]
Antworten
- Michael Grimm (12.02.2008 23:32)
- Holger Weiss (13.02.2008 00:13)
- Michael Grimm (13.02.2008 21:59)
