From: Les Mikesell <les@futuresource.com>
To: Tobias DiPasquale <codeslinger@gmail.com>
Cc: netfilter@lists.netfilter.org
Subject: Re: kernel-2.6: ipsec without devices
Date: Thu, 05 Aug 2004 10:48:43 -0500 [thread overview]
Message-ID: <1091720922.14493.16.camel@moola.futuresource.com> (raw)
In-Reply-To: <876ef97a04080506051db8a52f@mail.gmail.com>
On Thu, 2004-08-05 at 08:05, Tobias DiPasquale wrote:
> On Thu, 05 Aug 2004 07:35:09 -0500, Les Mikesell <les@futuresource.com> wrote:
> > A more fundamental question: does anyone know why Linux uses
> > pseudo devices for networking instead of having real names
> > in /dev with associated permissions and inodes connected
> > to drivers by major/minor numbers? It seems odd not to
> > be able to control access to /dev/tcp by group permisions
> > like you can every other device.
>
> Because network devices aren't easily manipulated using the standard
> UNIX "everything is a file" methodology. They are packet-oriented, as
> opposed to character- or block-oriented and as such, the normal
> read()/write()/close()/etc suite of system calls doesn't make sense
> for network devices (therefore, there's no reason to have a /dev file
> for them).
But it still makes as much sense to require open() to pass the
access control restrictions as it does for every other device.
> Also, network devices push packets towards the kernel
> asynchronously (as far as the kernel's concerned, anyway);
> chrdev/blkdev devices do so in response to some kind of request. No
> UNIX(-alike) that I know of has /dev files that correspond to network
> devices.
I've forgotten the details because it was years ago, but I'm sure
the last 'real' SysVr4 I used (perhaps Dell's, or AT&T's) had a
/dev/tcp or similar device that was opened as a step in opening
a socket and subject to the same rules as every other unix device.
A local ISP back in the days when people would telnet in to
access character-mode email/news, etc. used this to distinguish
accounts that could make direct outbound connections from those
that could only run programs to access the local mailbox and
news spool. I was very surprised when I first saw that Linux
omitted such a basic basic security concept of unix (all the
magic happens in open()). As far as the network goes, it is
the same thing as Lindows/Linspire defaulting to letting everyone
run as root.
---
Les Mikesell
les@futuresource.com
next prev parent reply other threads:[~2004-08-05 15:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-05 9:33 kernel-2.6: ipsec without devices richard lucassen
2004-08-05 10:09 ` Antony Stone
2004-08-05 10:25 ` richard lucassen
2004-08-05 12:35 ` Les Mikesell
2004-08-05 13:05 ` Tobias DiPasquale
2004-08-05 15:48 ` Les Mikesell [this message]
2004-08-05 16:35 ` Tobias DiPasquale
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1091720922.14493.16.camel@moola.futuresource.com \
--to=les@futuresource.com \
--cc=codeslinger@gmail.com \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.