nntp2http.com
Posting
Suche
Optionen
Hilfe & Kontakt

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
* 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