The ''Session Tty'' Manager

Total Page:16

File Type:pdf, Size:1020Kb

The ''Session Tty'' Manager The ``Session Tty'' Manager S.M. Bellovin ulysses!smb AT&T Bell Laboratories Murray Hill, NJ 07974 ABSTRACT In many UNIXÒ systems, it is possible for a program to retain access to the login terminal after the user has logged out. This poses obvious security risks and can also confuse the modem control signals. We solve this for System V by adding a layer of indirection known as the session tty driver. At login time, a session device is linked to the physical terminal. User programs have access to the session device only, and may not open the physical line. Upon logout or carrier drop, the link is severed. New login sessions are given new session devices, and are thus insulated from persistent processes. Use of session devices is controlled by a new system process known as the session manager; by means of suitable plumbing primitives, a ``reconnect after line drop'' facility can easily be implemented. 1. INTRODUCTION ``Any software problem can be solved by adding another layer of indirection.'' When a user logs on to a UNIXÒ system, a shell is ®red up with ®le descriptors 0, 1, and 2 connected to the physical tty device used. All commands executed by that user are descendants of the shell, and normally use the same tty device for input and output. These associations Ð so fundamental to the design of the system Ð cause trouble under certain circumstances. These problems may be solved by adding a level of indirection called the ``session manager''. Before we discuss the solution, it is, of course, helpful to know what problems it claims to cure. There are several, mostly having to do with ending conditions: 1. When the physical device receives an external close indication Ð i.e., when carrier has dropped, the user's terminal has been turned off or disconnected, or a network close request is received Ð this fact must be propagated to all processes using that terminal. It is not suf®cient to send SIGHUP. Some processes may have the signal ignored; others may not have the device as their controlling tty, and hence will not receive the signal at all. In either case, the result is the same: the next user of the line can receive some strange and wondrous garbage. 2. When the login shell Ð the process group leader Ð exits, the ``session'' (whatever that is) should end. Access rights to the terminal by any child processes should be revoked, regardless of whether the physical connection has been broken. If we are dealing with a network connection, such a disassociation may be needed to complete the protocol close processing. The system currently attempts to deal with this by sending SIGHUP when a process group leader ends; as noted, this is often insuf®cient. 3. When the host signals external equipment (i.e., modems) that a terminal session has ended, typically by dropping DTR, it must then immediately spawn a new getty process, and re-enable DTR. Failure to do either causes trouble: some other process may try to read from the line instead of getty1, or the line may appear to be dead, thus blocking a telephone ``hunt group''. - 1 - Historically, these requirements have been a very fruitful source of bugs. Most versions of the UNIX system either suffer from such bugs, contain large amounts of code to try to avoid them (i.e., forceclose() in the 9th Edition and 4.nBSD kernels), or both. None of these solutions is particularly satisfactory. The session tty mechanism avoids all of these problems by decoupling the physical tty device from the tty device visible to the user. A logical connection is established at login time; it is severed when either the physical device notices that the connection has dropped, or when the login shell exits. In addition to solving the original problem, there are several other bene®ts to session ttys: 1. Permitting a user to reconnect to a session after a physical hangup is easy. 2. Remote login sessions can be assigned ``tty'' names for /etc/utmp entries; thus, they will show up via who. 3. The /etc/utmp entry for the login session will remain around while any child processes persist. This helps system administrators track down hidden resource consumers. 4. Resources allocated to a session Ð say, a tape drive assigned to a user for the duration of several commands Ð should be revoked when the session ends. In current systems, it is very hard to determine when this is true. 5. Certain stream modules whose usage must be beyond the user's control (i.e, encryption or audit modules) can be protected from tampering. 6. Non-login sessions Ð circuit-based network connections, cron jobs, etc. Ð can have utmp entries as well. 7. Depending on certain design questions that are not yet clear, session ttys may provide a clean solution to the problem of which window is logged in when using layers. 8. Again, depending on certain as-yet unresolved questions, use of tty lines for two-way traf®c may become signi®cantly cleaner and easier. The implementation discussed here is for System V Release 3, as it heavily relies on streams[1] and on several other unique features, such as multiplexor devices and clone devices.2 Some features not in the standard system, such as a streams-based terminal line discipline, are also used. It is possible to implement the session manager on other versions of the UNIX system, but it is somewhat more dif®cult to do so. 2. HOW IT'S DONE There are three key components to the new design: the session manager, a multiplexed device driver known as sesstty, and one or more line managers. Depending on the exact hardware and software con®guration, the line manager may be a separate process, part of an existing ``listener'' process, or part of the session manager itself. 2.1 The Current Structure Before we discuss the new implementation, let us review the current login management structure. When the system makes a transition to multi-user state, /etc/init creates a child process for each tty line, as de®ned in /etc/inittab; each child process in turn executes /etc/getty, which opens the actual device. When the open succeeds, getty sets up the hardware environment (principally the line speed), collects the user's login id, and passes control to /bin/login. As noted earlier, the physical device __________________ 1. The security implications of this are amusing; it allows a process to imitate getty and login, thus capturing users' passwords. 2. See the glossary at the end. - 2 - opened by getty is passed directly to login. Login validates the login id (i.e., veri®es a password), creates an entry in /etc/utmp3, sets up the user's environment, and passes control to the user's shell. The only fork() operation in the entire process is the one performed by init; the user's shell is thus a direct descendant of init, with a process id known to init. We refer to that process as a session process. When the shell terminates Ð that is, when the user logs off Ð init is noti®ed of the process id; it cleans up the utmp entry and spawns another getty process for that line. The following table summarizes the process: TABLE 1. Division of Responsibility ____________________________________________________________________ ____________________________________________________________________Program Function External triggers /etc/init Fork and invoke getty Previous session process died ____________________________________________________________________ Clean up /etc/utmp entry /etc/getty Hardware environment setup Line open succeeds ____________________________________________________________________ Collect login id /bin/login Validate login id Software environment setup ____________________________________________________________________ Create /etc/utmp entry /bin/sh (user session) ____________________________________________________________________ exit User logs off or line drops Network tty connections do not differ in any fundamental way. /etc/init is no longer in the picture; the login shell will be child of some network listener process. It in turn is responsible for cleaning up any utmp entries. Getty may or may not be used. 2.2 A Brave New World The primary conceptual change in the new system is that the physical device is no longer passed directly to login. Rather, a software pseudo-device Ð sesstty, as you probably guessed Ð is opened by getty. By dint of the clone device driver, a separate sesstty device is used for each session. Next, the physical line is spliced to the sesstty device by the I_LINK ioctl() call. For the duration of this session, all references to the line, including its /etc/utmp entry, are via the sesstty device instead. The following diagram summarizes the situation: __________________ 3. Strictly speaking, the /etc/utmp entry is created by init. This is primarily a bookkeeping entry, however; the signi®cant entry Ð i.e., the one showing that someone has logged in Ð is created by login. - 3 - user command user shell /dev/sess07 /dev/tty03 When the physical line drops, the connection between the session device and the physical device is broken. As shown below, a new invocation of getty can attempt to reopen the line, without affecting the old session device still being used. user command user /etc/getty shell /dev/sess07 /dev/tty03 The connection is also severed if the shell exits while any of its children are still running: - 4 - user command . /etc/getty . /dev/sess07 /dev/tty03 Although the new scheme appears to be a minor enhancement to the current system, there are actually several complicating factors. For one thing, we have added some new external events. A new getty process must be spawned when the link is severed; this may or may not be coincident with the demise of the session process.
Recommended publications
  • IEEE Std 1003.1-2008
    This preview is downloaded from www.sis.se. Buy the entire standard via https://www.sis.se/std-911530 INTERNATIONAL ISO/IEC/ STANDARD IEEE 9945 First edition 2009-09-15 Information technology — Portable Operating System Interface (POSIX®) Base Specifications, Issue 7 Technologies de l'information — Spécifications de base de l'interface pour la portabilité des systèmes (POSIX ®), Issue 7 Reference number ISO/IEC/IEEE 9945:2009(E) Copyright © 2001-2008, IEEE and The Open Group. All rights reserved This preview is downloaded from www.sis.se. Buy the entire standard via https://www.sis.se/std-911530 ISO/IEC/IEEE 9945:2009(E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. Neither the ISO Central Secretariat nor IEEE accepts any liability in this area. Adobe is a trademark of Adobe Systems Incorporated. Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies and IEEE members. In the unlikely event that a problem relating to it is found, please inform the ISO Central Secretariat or IEEE at the address given below.
    [Show full text]
  • UNIX Shell Programming (15CS35) Solution Internal Assessment
    UNIX Shell Programming (15CS35) Solution Internal Assessment- II November - 2016 1. Explain significance of following commands (2x5=10 M) i. cp ?????? progs Wild card ? matches any single character, hence the above command (cp) copies files whose names are six in length to progs directory ii. ls *.[xyz]* Wild card * matches any number of characters, hence the above command (ls) lists all the files having extension as either x, or y or z. iii. ls jones[0-9][0- 9][0-9] In the above command the character class[0-9] matches any digit between 0 to 9. Hence the above command lists all the files beginning with jones and having last three characters as any digit between 0 to 9. iv. echo * The above command lists all the file in the current directory. v. cp foo foo* The above command copies the file foo to file called foo*. Here the wild card * loses its meaning. 1. Write UNIX commands for the following (2 X 5= 10 M) i. Find and replace all the occurrences of unix with UNIX in the file after confirming the user. : 1,$s/unix/UNIX/gc ii. List all the files in the current directory which names are having exactly 5 characters and any number of characters in their extension. ls ?????.* iii. Copy all files stored in /home/vtu with .c, .cpp and .java extensions to progs sub- directory in current directory cp /home/vtu/*.{c,cpp,java} ./progs iv. Delete all files containing agra or agar in their file names. rm *ag[ra][ar]* v.
    [Show full text]
  • Operating Systems Processes
    Operating Systems Processes Eno Thereska [email protected] http://www.imperial.ac.uk/computing/current-students/courses/211/ Partly based on slides from Julie McCann and Cristian Cadar Administrativia • Lecturer: Dr Eno Thereska § Email: [email protected] § Office: Huxley 450 • Class website http://www.imperial.ac.uk/computing/current- students/courses/211/ 2 Tutorials • No separate tutorial slots § Tutorials embedded in lectures • Tutorial exercises, with solutions, distributed on the course website § You are responsible for studying on your own the ones that we don’t cover during the lectures § Let me know if you have any questions or would like to discuss any others in class 3 Tutorial question & warmup • List the most important resources that must be managed by an operating system in the following settings: § Supercomputer § Smartphone § ”Her” A lonely writer develops an unlikely relationship with an operating system designed to meet his every need. Copyright IMDB.com 4 Introduction to Processes •One of the oldest abstractions in computing § An instance of a program being executed, a running program •Allows a single processor to run multiple programs “simultaneously” § Processes turn a single CPU into multiple virtual CPUs § Each process runs on a virtual CPU 5 Why Have Processes? •Provide (the illusion of) concurrency § Real vs. apparent concurrency •Provide isolation § Each process has its own address space •Simplicity of programming § Firefox doesn’t need to worry about gcc •Allow better utilisation of machine resources § Different processes require different resources at a certain time 6 Concurrency Apparent Concurrency (pseudo-concurrency): A single hardware processor which is switched between processes by interleaving.
    [Show full text]
  • Moxa Nport Real TTY Driver for Arm-Based Platform Porting Guide
    Moxa NPort Real TTY Driver for Arm-based Platform Porting Guide Moxa Technical Support Team [email protected] Contents 1 Introduction ...................................................................................2 2 Porting to the Moxa UC-Series—Arm-based Computer ....................2 2.1 Build binaries on a general Arm platform ...................................................... 2 2.2 Cross-compiler and the Real TTY driver ........................................................ 3 2.3 Moxa cross-compiling interactive script......................................................... 4 2.4 Manually build the Real TTY driver with a cross-compiler ................................ 5 2.5 Deploy cross-compiled binary to target......................................................... 8 3 Porting to Raspberry Pi OS .............................................................9 4 Porting to the Yocto Project on Raspberry Pi ................................ 10 4.1 Prerequisite............................................................................................... 10 4.2 Create a Moxa layer for the Yocto Project..................................................... 11 4.3 Install a Moxa layer into the Yocto Project.................................................... 17 4.4 Deploy the Yocto image in Raspberry Pi ....................................................... 17 4.5 Start the Real TTY driver in Raspberry Pi ..................................................... 18 4.6 Set the default tty mapping to the Real TTY configuration ............................
    [Show full text]
  • Openextensions POSIX Conformance Document
    z/VM Version 7 Release 1 OpenExtensions POSIX Conformance Document IBM GC24-6298-00 Note: Before you use this information and the product it supports, read the information in “Notices” on page 73. This edition applies to version 7, release 1, modification 0 of IBM z/VM (product number 5741-A09) and to all subsequent releases and modifications until otherwise indicated in new editions. Last updated: 2018-09-12 © Copyright International Business Machines Corporation 1993, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents List of Tables........................................................................................................ ix About This Document............................................................................................xi Intended Audience......................................................................................................................................xi Conventions Used in This Document.......................................................................................................... xi Where to Find More Information.................................................................................................................xi Links to Other Documents and Websites.............................................................................................. xi How to Send Your Comments to IBM....................................................................xiii Summary of Changes for z/VM
    [Show full text]
  • Printing Printf: Formatted Printing
    Printing printf: formatted printing So far we have just been copying stuff from standard-in, files, pipes, etc to the screen or another file. Say I have a file with names and phone numbers. I would like to print it out with vertically aligned columns. (so my printout is not in the same format as the input file) File contents: Desired display: Bob 4929 Bob 4929 Chuck 4882 Chuck 4882 printf is a command from the C programming language to control printing. Shell script #!/bin/bash printf "Hello world.\n" a=`echo Hello world. | wc | nawk '{print $2}' ` printf "This phrase contains %d words\n" $a Run it alpaca.ceri.memphis.edu512:> printex.sh Hello world. This phrase contains 2 words alpaca.ceri.memphis.edu513:> #!/bin/bash printf "Hello world.\n" a=`echo Hello world. | wc | nawk '{print $2}' ` printf "This phrase contains %d words\n" $a We need the double quotes “ . “ to define an argument (the stuff inside the quotes) for printf. #!/bin/bash printf "Hello world.\n" a=`echo Hello world. | wc | nawk '{print $2}' ` printf "This phrase contains %d words\n" $a The argument in double quotes has - Regular text (“Hello world”, “This text contains “) - Some funny new thing - %d – a format specifier. - The already known specification for a new line - \n #!/bin/bash printf "Hello world.\n" a=`echo Hello world. | wc | nawk '{print $2}' ` printf "This phrase contains %d words\n" $a We also have another argument, the $a, which is a shell variable, at the end. Note that the items are delimited with spaces, not commas.
    [Show full text]
  • System Calls & Signals
    CS345 OPERATING SYSTEMS System calls & Signals Panagiotis Papadopoulos [email protected] 1 SYSTEM CALL When a program invokes a system call, it is interrupted and the system switches to Kernel space. The Kernel then saves the process execution context (so that it can resume the program later) and determines what is being requested. The Kernel carefully checks that the request is valid and that the process invoking the system call has enough privilege. For instance some system calls can only be called by a user with superuser privilege (often referred to as root). If everything is good, the Kernel processes the request in Kernel Mode and can access the device drivers in charge of controlling the hardware (e.g. reading a character inputted from the keyboard). The Kernel can read and modify the data of the calling process as it has access to memory in User Space (e.g. it can copy the keyboard character into a buffer that the calling process has access to) When the Kernel is done processing the request, it restores the process execution context that was saved when the system call was invoked, and control returns to the calling program which continues executing. 2 SYSTEM CALLS FORK() 3 THE FORK() SYSTEM CALL (1/2) • A process calling fork()spawns a child process. • The child is almost an identical clone of the parent: • Program Text (segment .text) • Stack (ss) • PCB (eg. registers) • Data (segment .data) #include <sys/types.h> #include <unistd.h> pid_t fork(void); 4 THE FORK() SYSTEM CALL (2/2) • The fork()is one of the those system calls, which is called once, but returns twice! Consider a piece of program • After fork()both the parent and the child are ..
    [Show full text]
  • Process Relationships (Chapter 9 )
    Process Relationships (Chapter 9 ) Terminal Logins & Network Logins Process Groups and Sessions Job Control Relationships explained with examples Amy Lin, UAH 6/25/2019 Terminal Login Procedure init getty login shell “init” • At old time, the sysadmin would create a text file called /etc/ttys, each line would specify the device name and other parameters passed to getty • On Linux, the information is in /etc/inittab, a typical line in inittab is - 5:2345:respawn:/sbin/mingetty tty5 (man 5 inittab) - mingetty is almost the same as getty except it’s not suitable for serial line connections , you might consider to use (m)getty if dialup connection is needed. • On system startup, init reads inittab to get terminal information and fork/exec a “getty” process for each terminal “getty” • Calls open for the terminal device (read and write) • Opens descriptors 0, 1, and 2 to the device and outputs “login:” • Waits for someone to enter a user name Amy Lin, UAH 6/25/2019 The “login” After user enters a user name, login invokes exec function execle(“/bin/login”, “login”, “-p”, username, (char*)0, envp); • login calls “getpwnam” to fetch the password file entry • login reads the entered password, call crypt (3) to encrypt the password then compare to the encrypted password file entry • If log incorrectly, login exits with “1”, init then respawns getty to start over In successful login, login performs the following - Change to user’s home directory - Change permissions of terminal device so we can read from and write to it - Set group IDs - Initialize environment variables, such as PATH, HOME, SHELL, USER, LOGNAME Amy Lin, UAH 6/25/2019 The “shell” At the end of login process, a login shell is invoked with fork/exec execl(“/bin/sh”,“-sh”,(char*)0) - The prefix “-” before argv[0] is a flag to all the shells that they are being invoked as a login shell.
    [Show full text]
  • Unix Commands (09/04/2014)
    Unix Commands (09/04/2014) • Access control – login <login_name> – exit – passwd <login_name> – yppassswd <loginname> – su – • Login as Super user – su <login> • Login as user <login> • Root Prompt – [root@localhost ~] # • User Prompt – [bms@raxama ~] $ On Line Documentation – man <command/topic> – info <command/topic> • Working with directories – mkdir –p <subdir> ... {-p create all directories in path if not present} mkdir –p /2015/Jan/21/14 will create /2015, Jan, 21 & 14 in case any of these is absent – cd <dir> – rm -r <subdir> ... Man Pages • 1 Executable programs or shell commands • 2 System calls (functions provided by the kernel) • 3 Library calls (functions within program libraries) • 4 Special files (usually found in /dev) • 5 File formats and conventions eg /etc/passwd • 6 Games • 7 Miscellaneous (including macro packages and conventions), e.g. man(7), groff(7) • 8 System administration commands (usually only for root) • 9 Kernel routines [Non standard] – man grep, {awk,sed,find,cut,sort} – man –k mysql, man –k dhcp – man crontab ,man 5 crontab – man printf, man 3 printf – man read, man 2 read – man info Runlevels used by Fedora/RHS Refer /etc/inittab • 0 - halt (Do NOT set initdefault to this) • 1 - Single user mode • 2 - Multiuser, – without NFS (The same as 3, if you do not have networking) • 3 - Full multi user mode w/o X • 4 - unused • 5 - X11 • 6 - reboot (Do NOT set init default to this) – init 6 {Reboot System} – init 0 {Halt the System} – reboot {Requires Super User} – <ctrl> <alt> <del> • in tty[2-7] mode – tty switching • <ctrl> <alt> <F1-7> • In Fedora 10 tty1 is X.
    [Show full text]
  • Gnu Coreutils Core GNU Utilities for Version 5.93, 2 November 2005
    gnu Coreutils Core GNU utilities for version 5.93, 2 November 2005 David MacKenzie et al. This manual documents version 5.93 of the gnu core utilities, including the standard pro- grams for text and file manipulation. Copyright c 1994, 1995, 1996, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”. Chapter 1: Introduction 1 1 Introduction This manual is a work in progress: many sections make no attempt to explain basic concepts in a way suitable for novices. Thus, if you are interested, please get involved in improving this manual. The entire gnu community will benefit. The gnu utilities documented here are mostly compatible with the POSIX standard. Please report bugs to [email protected]. Remember to include the version number, machine architecture, input files, and any other information needed to reproduce the bug: your input, what you expected, what you got, and why it is wrong. Diffs are welcome, but please include a description of the problem as well, since this is sometimes difficult to infer. See section “Bugs” in Using and Porting GNU CC. This manual was originally derived from the Unix man pages in the distributions, which were written by David MacKenzie and updated by Jim Meyering.
    [Show full text]
  • Processes in Linux/Unix
    Processes in Linux/Unix A program/command when executed, a special instance is provided by the system to the process. This instance consists of all the services/resources that may be utilized by the process under execution. • Whenever a command is issued in unix/linux, it creates/starts a new process. For example, pwd when issued which is used to list the current directory location the user is in, a process starts. • Through a 5 digit ID number unix/linux keeps account of the processes, this number is call process id or pid. Each process in the system has a unique pid. • Used up pid’s can be used in again for a newer process since all the possible combinations are used. • At any point of time, no two processes with the same pid exist in the system because it is the pid that Unix uses to track each process. Initializing a process A process can be run in two ways: 1. Foreground Process : Every process when started runs in foreground by default, receives input from the keyboard and sends output to the screen. When issuing pwd command $ ls pwd Output: $ /home/geeksforgeeks/root When a command/process is running in the foreground and is taking a lot of time, no other processes can be run or started because the prompt would not be available until the program finishes processing and comes out. 2. Backround Process : It runs in the background without keyboard input and waits till keyboard input is required. Thus, other processes can be done in parallel with the process running in background since they do not have to wait for the previous process to be completed.
    [Show full text]
  • Systems Supplement for COP 3601
    Systems Guide for COP 3601: Introduction to Systems Software Charles N. Winton Department of Computer and Information Sciences University of North Florida 2010 Chapter 1 A Basic Guide for the Unix Operating System 1. 1 Using the Unix On-line Manual Pages Facility The following are some of the Unix commands for which you may display manual pages: cal cat cd chmod cp cut date echo egrep ex fgrep file find gcc gdb grep kill less ln locate ls mail make man mesg mkdir mv nohup nl passwd pr ps pwd rm rmdir set sleep sort stty tail tee time touch tr tty uname umask unset vim wall wc which who whoami write For example, to display the manual pages for the command "cp" enter man cp Note that you may also enter man man to find out more about the "man" command. In addition there may be commands unique to the local environment with manual pages; e.g., man turnin accesses a manual page for a project submission utility named Aturnin@ that has been added to the system. If you enter a command from the Unix prompt that requires an argument, the system will recognize that the command is incomplete and respond with an error message. For example, if the command "cp" had been entered at the Unix prompt the system would respond with the information such as shown below: cp: missing file arguments Try `cp --help' for more information. The "cp" command is a copy command. If the arguments which tell the command which file to copy and where to locate the copied file are missing, then the usage error message is generated.
    [Show full text]