By default, inn only allows reader access from localhost. I like that
for simplicity; if you want to use a client from another system, you
could set up an SSH tunnel.

However, suppose I gave accounts to half a dozen friends, and one of
them started posting like an asshole. Is there any way to tie a post
back to a Unix username as the server admin? I'm kinda assuming no,
because the TCP connection basically anonymizes it, right?

john

John <john@building-m.simplistic-anti-spam-measure.net> writes:

> However, suppose I gave accounts to half a dozen friends, and one of
> them started posting like an asshole. Is there any way to tie a post
> back to a Unix username as the server admin? I'm kinda assuming no,
> because the TCP connection basically anonymizes it, right?

Yup, that's correct. It's technically possible to retain enough trace
information about the connections (via iptables logging for example) that
you could track it down, but this is not something that the news server
itself can do.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

John wrote:
> them started posting like an asshole. Is there any way to tie a post
> back to a Unix username as the server admin? I'm kinda assuming no,
> because the TCP connection basically anonymizes it, right?

ident (RFC 1413) may help

Am 16.07.2023 um 20:47:04 Uhr schrieb Urs Janßen:

> John wrote:
> > them started posting like an asshole. Is there any way to tie a post
> > back to a Unix username as the server admin? I'm kinda assuming no,
> > because the TCP connection basically anonymizes it, right?
>
> ident (RFC 1413) may help

IIRC this only works until the connection of the user is closed.

Marco Moock wrote:
>> ident (RFC 1413) may help
> IIRC this only works until the connection of the user is closed.

(one of) the problem(s) with ident is that one can only trust answers
from systems where you run the service (no issue here as the connection
are comming from localhost) and that the service which may get abused
(nntpd) needs to do the lookup (don't know if nnrpd still does).

Urs Janßen <urs@buil.tin.org> writes:

> (one of) the problem(s) with ident is that one can only trust answers
> from systems where you run the service (no issue here as the connection
> are comming from localhost) and that the service which may get abused
> (nntpd) needs to do the lookup (don't know if nnrpd still does).

Yeah, there's still an authprog to do ident lookups. That's a good
thought; that hadn't occurred to me as a possible solution.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Russ Allbery <eagle@eyrie.org> writes:

> Urs Janßen <urs@buil.tin.org> writes:
>
>> (one of) the problem(s) with ident is that one can only trust answers
>> from systems where you run the service (no issue here as the connection
>> are comming from localhost) and that the service which may get abused
>> (nntpd) needs to do the lookup (don't know if nnrpd still does).
>
> Yeah, there's still an authprog to do ident lookups. That's a good
> thought; that hadn't occurred to me as a possible solution.

This is a great idea and I've enabled it to *apparent* success (it
logged an error message about the ident daemon rejecting connections
until I actually installed identd, now it doesn't log), but I don't see
any logs letting me know that a user has posted, just the usual e.g.

nnrpd[2735057]: localhost post ok <1234567890.fsf@building-m.net>

Is there a log kept elsewhere after authentication?

Thanks,

john

In <86wmywpsey.fsf@building-m.net> on Wed, 19 Jul 2023 04:05:25,
John wrote:
> This is a great idea and I've enabled it to *apparent* success (it
> logged an error message about the ident daemon rejecting connections
> until I actually installed identd, now it doesn't log), but I don't see
> any logs letting me know that a user has posted, just the usual e.g.
>
> nnrpd[2735057]: localhost post ok <1234567890.fsf@building-m.net>
>
> Is there a log kept elsewhere after authentication?

! this is based on inn < 2.3 knowledge (the last version with local spool
! and the old overview names) some things may have changed (a lot).

the username is just logged on connection (in news.notice) you have to
track the pid afterwards, e.g.:

akw% grep urs /var/log/news/news.notice
Jul 19 06:21:59 akw nnrpd[19289]: akw.example.org user urs

akw% grep 19289 /var/log/news/news.notice| grep post
Jul 19 06:22:28 akw nnrpd[19289]: akw.example.org post ok <u97oe2$iqp$1@news.example.org>
Jul 19 06:23:40 akw nnrpd[19289]: akw.example.org posts received 1 rejected 0

Urs Janßen <urs@buil.tin.org> writes:

> In <86wmywpsey.fsf@building-m.net> on Wed, 19 Jul 2023 04:05:25,
> John wrote:
>> This is a great idea and I've enabled it to *apparent* success (it
>> logged an error message about the ident daemon rejecting connections
>> until I actually installed identd, now it doesn't log), but I don't see
>> any logs letting me know that a user has posted, just the usual e.g.
>>
>> nnrpd[2735057]: localhost post ok <1234567890.fsf@building-m.net>
>>
>> Is there a log kept elsewhere after authentication?
>
> ! this is based on inn < 2.3 knowledge (the last version with local spool
> ! and the old overview names) some things may have changed (a lot).
>
> the username is just logged on connection (in news.notice) you have to
> track the pid afterwards, e.g.:
>
> akw% grep urs /var/log/news/news.notice
> Jul 19 06:21:59 akw nnrpd[19289]: akw.example.org user urs
>
> akw% grep 19289 /var/log/news/news.notice| grep post
> Jul 19 06:22:28 akw nnrpd[19289]: akw.example.org post ok <u97oe2$iqp$1@news.example.org>
> Jul 19 06:23:40 akw nnrpd[19289]: akw.example.org posts received 1 rejected 0

It seems I spoke too soon... I thought adding "res" would resolve the
username without necessarily requiring further authentication, but Gnus
is prompting me for a password and I see this in my log file:

nnrpd[2796111]: localhost (::1) connect - port 119
nnrpd[2796111]: Reading access from /etc/news/readers.conf
nnrpd[2796111]: localhost res starting resolver ident
nnrpd[2796111]: localhost res resolver successful, user john
nnrpd[2796111]: localhost res john
nnrpd[2796111]: localhost no_match_user john <localhost>
nnrpd[2796111]: localhost no_access_realm

Is there a way to do the username resolution but *not* prompt for a
password at all? I can write a tiny auth program that just accepts any
password, but it's still kind of a hassle vs not having to provide
anything at all -- at that point I'd just as soon use ckpasswd and do
real authentication.

john

John <john@building-m.simplistic-anti-spam-measure.net> writes:

> It seems I spoke too soon... I thought adding "res" would resolve the
> username without necessarily requiring further authentication, but Gnus
> is prompting me for a password and I see this in my log file:

> nnrpd[2796111]: localhost (::1) connect - port 119
> nnrpd[2796111]: Reading access from /etc/news/readers.conf
> nnrpd[2796111]: localhost res starting resolver ident
> nnrpd[2796111]: localhost res resolver successful, user john
> nnrpd[2796111]: localhost res john
> nnrpd[2796111]: localhost no_match_user john <localhost>
> nnrpd[2796111]: localhost no_access_realm

> Is there a way to do the username resolution but *not* prompt for a
> password at all?

You have to make sure there's an access stanza that matches all possible
identities returned from the auth stanza. In your case, presumably that
means you want an access stanza with users: "*".

The way readers.conf works is that the auth block assigns an identity and
the access block that matches that identity says what permissions the user
has. Presumably previously you had an auth block that matched users from
localhost and assigned the <localhost> identity and had an access stanza
that matched that identity, but now that you're using ident, the identity
is now something like "john" instead of "<localhost>" and it's not
matching any more.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Russ Allbery <eagle@eyrie.org> writes:

> John <john@building-m.simplistic-anti-spam-measure.net> writes:
>
>> It seems I spoke too soon... I thought adding "res" would resolve the
>> username without necessarily requiring further authentication, but Gnus
>> is prompting me for a password and I see this in my log file:
>
>> nnrpd[2796111]: localhost (::1) connect - port 119
>> nnrpd[2796111]: Reading access from /etc/news/readers.conf
>> nnrpd[2796111]: localhost res starting resolver ident
>> nnrpd[2796111]: localhost res resolver successful, user john
>> nnrpd[2796111]: localhost res john
>> nnrpd[2796111]: localhost no_match_user john <localhost>
>> nnrpd[2796111]: localhost no_access_realm
>
>> Is there a way to do the username resolution but *not* prompt for a
>> password at all?
>
> You have to make sure there's an access stanza that matches all possible
> identities returned from the auth stanza. In your case, presumably that
> means you want an access stanza with users: "*".
>
> The way readers.conf works is that the auth block assigns an identity and
> the access block that matches that identity says what permissions the user
> has. Presumably previously you had an auth block that matched users from
> localhost and assigned the <localhost> identity and had an access stanza
> that matched that identity, but now that you're using ident, the identity
> is now something like "john" instead of "<localhost>" and it's not
> matching any more.

Ah, that makes sense, and indeed that change seems to have things
working as expected -- if I connect via localhost, I'm not prompted for
a password but I see in the logs that it identifies my username. If I
attempt to connect from outside, I still get booted off with a 502.

Thank you,

John