From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4C02C433E7 for ; Fri, 9 Oct 2020 04:47:55 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 298432223C for ; Fri, 9 Oct 2020 04:47:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=vt-edu.20150623.gappssmtp.com header.i=@vt-edu.20150623.gappssmtp.com header.b="Fr082nq6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 298432223C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=vt.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94) (envelope-from ) id 1kQkJO-0008GU-Tw; Fri, 09 Oct 2020 00:47:22 -0400 Received: from mail-qt1-x831.google.com ([2607:f8b0:4864:20::831]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kQkJM-0008GP-AO for kernelnewbies@kernelnewbies.org; Fri, 09 Oct 2020 00:47:20 -0400 Received: by mail-qt1-x831.google.com with SMTP id c5so7060071qtw.3 for ; Thu, 08 Oct 2020 21:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vt-edu.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:subject:in-reply-to:references:mime-version :content-transfer-encoding:date:message-id; bh=Q/BG4QkuXdZrvveMa9kIVBY7cPA/SYlBvmrriIw0KAM=; b=Fr082nq61ynAUplQuw/xLpJAsFcLuLo1jh+V9Bx8yxJ6xvcOUGWUK0UV1NsHqBQS0y BqrpBfMpBTTj3FPdfINenJ2cxLJukbUMBhQA07sUyv4nJ4qANdYJNlEUz4jNCnSMd5WO u01K00ZMOwEFLYe5yYTQrEp7rvXpMVA8PNGZ7/IgqgupnBb4fh+iBZf/TA2r5Ji3hFc4 qlRmMEdqCyGO5QIANIFYtZ2rIMwI+bZc8ML5leAgXaBb655aSTvFKe1gzBzyjqlUbWP3 9p6zxzigN0ZGckHMrIZctQrnZlN4rQR6KJiJjPp+GlTAkOt2Zx6KzluhN0Apmi2pKuhw 7YmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=Q/BG4QkuXdZrvveMa9kIVBY7cPA/SYlBvmrriIw0KAM=; b=bU5UBk5lkEjqhayL7Q6+crhNzpfVfXX7RFmNaTvUMLHIhqqix/1jwSGGYNgbkpGs1x euFhcNtItQYCQslLc2VwCPcpaJtI8k5qhvIu4dh0GFfG3K6bzvoSEjp1zmCaCdkHhQrJ yXpShqo7LBItG+B3TMpUNbWXDNZuonBfGtctbX+lfQEh6WWeSwr8jouwQuNAA8UbQ3Mw kbV1NWYEOq1n0MEb3niHjJVu+qVMuvomer/52vUSFpDauSgzrFpkd4foS39r9hTPKAnU FAHqsUaXEhlP3+jl9RmPFEPr9jHwHHCV4IVs3HtIStoo5Z2jpnbDFGvq8sUMVq4OsqVA qTpg== X-Gm-Message-State: AOAM533wEPwyQuGW+tQGK4pBx5lJa54SBjtXp0IVocKlVh4E0FpS5sxw jyEo4enpm6qPBnyUkBlPRTz+aw== X-Google-Smtp-Source: ABdhPJzeH4iVZIGxyr6LpKB17QquUNkoh8MbQlbrK8D6MSPUXJPstURNgL/zQVmCIWYs9mOJNL3UJQ== X-Received: by 2002:ac8:977:: with SMTP id z52mr12133645qth.132.1602218837105; Thu, 08 Oct 2020 21:47:17 -0700 (PDT) Received: from turing-police ([2601:5c0:c000:a8c1::359]) by smtp.gmail.com with ESMTPSA id x5sm4893551qtk.68.2020.10.08.21.47.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2020 21:47:15 -0700 (PDT) From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev To: sebastian.fricke.linux@gmail.com Subject: Re: How are the standard file descriptors implemented? In-Reply-To: <20201007061117.mpjxzvztzcr7a2p4@basti.Speedport_W_724V_Typ_A_05011603_06_001> References: <20201007061117.mpjxzvztzcr7a2p4@basti.Speedport_W_724V_Typ_A_05011603_06_001> Mime-Version: 1.0 Date: Fri, 09 Oct 2020 00:47:14 -0400 Message-ID: <406727.1602218834@turing-police> Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5124536730058342189==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============5124536730058342189== Content-Type: multipart/signed; boundary="==_Exmh_1602218834_122947P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1602218834_122947P Content-Type: text/plain; charset=us-ascii On Wed, 07 Oct 2020 08:11:17 +0200, Sebastian Fricke said: > - The standard file descriptors are an abstraction layer in between an > output device like a monitor and an input device like a keyboard. In > the old days, these were configured directly to the terminals. There's "in the old days", and then there's the age of myths and legend, which some of us were already around for. :) Yes, files were configured to terminals. Unless they were connected to a pipe to another program, or to a file, or to a network socket, or... In other words, only configured to terminals by default, if you were running from an interactive source like a terminal or console. Redirection to a file was there from pretty much the beginning of Unix. https://en.wikipedia.org/wiki/Everything_is_a_file Pipes date back to 1973 or so.. https://en.wikipedia.org/wiki/Pipeline_(Unix) BSD 4.2 brought us sockets, although I admit not being sure when bash sprouted the /dev/tcp and /dev/udp pseudo-devices. (And also brought loads of fun when 4.3 showed up with a different concept of broadcast addresses, meaning that a 4.2->4.3 upgrade was a flag-day for the entire subnet... or else. :) And I remember more than one security exploit against programs that assumed that stdout was connected to someplace rational, which led to hilarity and hjinks if you invoked the program with file descriptor zero closed, it would open some security-relevant file like /etc/passwd (possibly inplicitly via a call to getpwent() or similar, and then invoke some other program, which now had fd 0 stdout connected to /etc/passwd. (vipw got bit by this, among other programs...) > - Who creates that device /dev/pts/4 ? I was currently not able to > locate this information. The Nth program to open a generic pts device. It can then be fed to dup() to create copies, passed across a fork/exec, or pretty much anything else legal to do with an open file descriptor. In a GUI environment, it's probably xterm/Gnome-terminal/etc... > - How is that device connected to my keyboard/monitor? Depends. if you're on a virtual console, it's probably using /dev/ttyN instead. If you're running an X-based GUI, it gets complicated. :) Normally, xterm or gnome-terminal or whatever, creates a pty, sets up fd 0 1 and 2 to point to it, opens up its own file descriptors for the other end of the 3 pipes, and then fork/execs bash or whatever program. So if bash or a child scribble on stdout, xterm then reads from the other end of the pipe and then goes through a *very* long and ugly process to map that to pixels on the screen. input goes through an equally convoluted process from a keyboard event being read by the X server (usually via the evdev driver in most modern distros), then passed as an X event to xterm or gnome-terminal, which then reads it and synthesizes a character input and pushes it down the pipe to the bash or vi or whatever is currently the process reading from the terminal. Meanwhile, bash does its own games when setting up to run a program, in order to get any redirections set up. > - Could I maybe create a simplified version, which just utilizes a file > for STDIN, STDOUT, STDERR. That are created by the init process and > inherited to all child processes? % your_command_here < your_stdin_file > your_stdout_file 2> your_stderr_file Done. Don't make it harder than you have to. > Maybe I could then redirect the > keyboard output to the STDIN file, the STDOUT file to the monitor > device etc. That's actually more complicated than just directing the file to wherever in the first place. (How complicated? The xterm source famously contained the comment "Here there be dragons. You are not expected to understand this" in the section of code that set up the ptys for the child process's initial fd 0/1/2. --==_Exmh_1602218834_122947P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Comment: Exmh version 2.9.0 11/07/2018 iQIVAwUBX3/rUgdmEQWDXROgAQLWqRAAit6xce4bRsBrN1aY746RpvDfAxpZZPOW XTxLmywzgStb+dtUjf7yWwbOAjZhdWgTn4FF/ypR7gVrgUIy+tIDspljTggvQRko zRuAGEvPwne8phNYk8D/BCjyOwggEprFV3o3ftdeBJsGELmHdLI/h9blUWVjk/Py eMvQTdK5B5zHk0sRXzML+2TMKDcCuiuDJdYBPw/Wit/CfNAbrq9pY33DfpuKpHOa BUY8k2kq9izpKzUuKUxOmeIKcTaYB/GdUSYuK4/qEZCjMK3+TyhBgsGvFGtf0r14 gKPy+DSk62Ue4tTukXu3xtF8oyH2OZX/x3oFZSeosw/Ndlx76ngku3+tPvrAzXdf tHlp9MLtupqWvoZ7exGVFoKAVyZLWL8odJrfm1MNQXNt6nsSGFgj1o1q+6LvEuNR /DULPSlDBSGdbwEw4+ir78FfOqT+56WqbOkv4uze2zeNFyvASHXUOXu1KpvrMXdm syXNivOfeSvQeHk3KIiRro56yxs07FOkOS+0eX+to3mFlbauKG2MVU7tUKSSYwAt FNYFH2Q7fAhpBvQqwGty5kPVHW14j9dJKV5yNY7CskCZh7bHkyQB21t4y+MN9AhS 7edfjZmWAY9rVW7o07ZEYQ8mFJMvl77bo5loQQEfVmnsc9OwJVeOb3AaP4fUjcfA h5+6YCUxctY= =2wVq -----END PGP SIGNATURE----- --==_Exmh_1602218834_122947P-- --===============5124536730058342189== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============5124536730058342189==--