brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/27/91)
In article <16048@sdcc6.ucsd.edu> cs163wcr@sdcc10.ucsd.edu (I support the U.N.) writes: > I have been hacking at these questions for a while, using various > reference books, with no real progress. That doesn't make them wizard-level questions. > [1] Can you access a file by its i-node number? Something like > (for C code) FILE *iopen (int inode, char *mode) ? With any reasonable efficiency? Not portably. > [2] With Internet sockets, how does a machine accept()ing a > socket connection know what machine is calling it? accept() has three parameters, the second of which is filled in with the address of the calling machine. > [3] I have a server program that reads my mail and does various > functions. One thing I would like it to do is send a "write" > message to other users when it gets a letter with subject > "WRITE user", sending the letter body as the message, but I > can't get write to work unless the output is a tty. How do > I fool write into thinking my pipe is a tty? You probably mean that the input is a pipe. In any case, use ``pty write'' in place of ``write''. pty was published in comp.sources.unix volume 23; the latest version is available via anonymous ftp to 128.122.128.22. > [4] How did you become a Unix Wizard? Who are you talking to? If you define ``wizard'' as someone who can write any program on the system, the answer should be obvious. Other definitions lead to other answers. ---Dan
sef@kithrup.COM (Sean Eric Fagan) (01/27/91)
In article <1991Jan26.142403.22812@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > I hope not. Otherwise permissions on directories wouldn't do much. I >do think the system design would have been cleaner if you only accessed >by i-node number, and mapping filename to inode was done outside the kernel. >But I doubt that I have many supporters in this "keep the kernel small" view. On the contrary, you actually have quite a few supporters of that view. But your approach is wrong, for the reason you pointed out. (Although... I believe that at least one version of SunOS allowed any user to access a file they had permission to, no matter what the permissions of the intervening directories were. That is, /home/sef/.private/foo, assuming foo readable by all, and .private mode 700, would still have allowed foo to be read by anyone who knew of it. And this is a *bug*! [I really hope it's been fixed, or, better yet, that I imagined the whole thing.]) Doug Gwyn, I think it was, had a system for "file handles," which are somewhat nice, but are mostly an extension of the currect file-descriptor theme. Note that none of the current setup requires that the filesystem go into the kernel. You can have the filesystem be a seperate process, if you wish. (And some of us wish... 8-)) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sef@kithrup.COM (Sean Eric Fagan) (01/27/91)
In article <120190@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >My advice to wannabes is to RTFM. All of it. Several times. Yes!!!! >Forget 90% of the books out there. They're trying to beat >around the bush for people who like to be led by the hand. Hint: if the book is by Kernighan, Ritchie, Thompson, Bach, Tannenbaum, McKusick et al, and a few others, then it's worthwhile. One of the most useful books I had, back when all I knew was some C, was _Advanced UNIX Programming_, by someone whose name I sadly forget. But it was a good text, and, after reading it, I went on to the more advanced books. (It was what I would actually consider an advanced beginner's book. Still useful.) >Ask questions if you get stuck. Don't worry if they are stupid >ones. We like them, they're easier to answer. We asked them too. But *please* ask them in the correct forum. If you're unsure, read the various comp.unix groups for a while, and send an email message to someone you think knowledgeable. Dan Bernstein, for example, is very knowledgeable, and is a lot more polite in his email than he is in his postings... (hi, dan 8-)) >Read source code. Unfortunately, less system source is available, >altho more public domain source is. In that respect, if you want to get into the system hacking side of wizardry, get Tannenbaum's _Operatings Systems: Design and Implementation_, which is an extremely good book in its own right, but you can also get source code to a unix-clone (minix) from the publishers. >Learn LISP. Learn why I said this. So you can learn to make parenthetical comments properly? 8-) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
bzs@world.std.com (Barry Shein) (01/28/91)
From: cs163wcr@sdcc10.ucsd.edu (I support the U.N.) >[1] Can you access a file by its i-node number? Something like > (for C code) FILE *iopen (int inode, char *mode) ? No, although NFS servers would find this handy and often have to simulate about the same thing. Well, let me modify that "no" with pointing out that of course you can do anything if you can access the raw disk and getting at the contents of a file given its inode number is a short afternoon's exercise, I've done it. So you could write a library routine, but only someone with the proper privs to open the raw disk could use it. The problem is security. Although all the permissions on the file itself are stored in the inode, you also have to verify that the path to the file is accessible by the process doing the open(). At the inode level all this information is non-existant and very hard to recreate. >[2] With Internet sockets, how does a machine accept()ing a > socket connection know what machine is calling it? Does > it rely on the calling program to tell it? Yes, essentially, the information is in the packets being sent. Some tiny amount of spoofing can be avoided if hardware addresses can be compared (e.g. via ARP caches), but basically that's all there is w/o adding authorization code. Of course, if the protocol is two-way the other side better be able to receive at that address also, which provides some security against spoofing by simply whacking packet addresses. >[3] I have a server program that reads my mail and does various > functions. One thing I would like it to do is send a "write" > message to other users when it gets a letter with subject > "WRITE user", sending the letter body as the message, but I > can't get write to work unless the output is a tty. How do > I fool write into thinking my pipe is a tty? Hmm, it's possible that you want to look at syslog(), depends on what you're really trying to do. You could also craft your own program to do this fairly easily, there's nothing magical about write (unless tty's are all protected on your system, in which case you'll need privilege.) >[4] How did you become a Unix Wizard? I'm learning various > features as I go, as I think of a use for them and/or > learn about them. Is there a more organized/better way? The easiest way is to have started with V6 and work hard for 15+ years...heh heh. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
mike@bria (01/28/91)
Another excellent book that I came across when I was getting started with UNIX was "UNIX System Programming" by Keith Haviland and Ben Salama, written in 1987. It's relatively small, and covers a number of useful topics. -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
tensmekl@infonode.ingr.com (Kermit Tensmeyer) (01/28/91)
In article <16048@sdcc6.ucsd.edu> cs163wcr@sdcc10.ucsd.edu -- Steve Boswell writes: >I have been hacking at these questions for a while, using various >reference books, with no real progress. Could someone please tell >me: > >[2] With Internet sockets, how does a machine accept()ing a > socket connection know what machine is calling it? Does > it rely on the calling program to tell it? > >I'm on 4.3 BSD Tahoe & the Internet, if that helps. > >Steve Boswell >whatis@ucsd.edu There is a function in the BSD suite of TCP/IP that has the following setup int recvfrom (s, buf, len, flags, from, fromlen) int s, len, flags; char *buf; struct sockaddr *from; int *fromlen; The structure Sockaddr contains the return address (Type IV address and Port number from which is was sent. This of course works in the datagram mode. When the connection is in the "connected mode" use the recv call. For further information, look up recv(2) and connect(2) in the man pages. --- All the wizards that I used to know and from whom I learned my craft have seemed to have gotten out of the bussines. Most of the folk who are still willing to try know the areas of the business that have given them problems, .. there is just to much to know. The books on my desk that sometimes get open are: Maurice Bach The Design of the UNIX Operating System Nemeth,Snyder,Seebass Unix System Adminstration Handbook Egain, Teixeira Writing A Unix Device Driver Schreiner Using C with Curses, Lex, and Yacc Kochan, Wood Unix Shell Programming Ellis, Stroustrup The Annotated C++ Reference Manual --- -- Kermit Tensmeyer | Intergraph Corporation UUCP: ...uunet!ingr!tensmekl | One Madison Industrial Park INTERNET: tensmekl@ingr.com | Mail Stop LR23A2 AT&T: (205)730-8127 | Huntsville, AL 35807-4201
lm@slovax.Eng.Sun.COM (Larry McVoy) (01/28/91)
In article <1991Jan27.093615.3231@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >useful books I had, back when all I knew was some C, was _Advanced UNIX >Programming_, by someone whose name I sadly forget. But it was a good text, >and, after reading it, I went on to the more advanced books. (It was what I >would actually consider an advanced beginner's book. Still useful.) The auther is Marc Rochkind, he who brought us SCCS. This is an excellent book for someone who knows the C programming language but not all the Unix goobers. --- Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com
ewoods@hemel.bull.co.uk (Eoin Woods) (01/28/91)
sef@kithrup.COM (Sean Eric Fagan) writes: >One of the most >useful books I had, back when all I knew was some C, was _Advanced UNIX >Programming_, by someone whose name I sadly forget. "Advanced UNIX PRogramming" - Marc Rochkind, Prentice Hall, 1985, ISBN 0-13-011818-4/1 -- Excellent! >>Learn LISP. Learn why I said this. So you can extend EMACS of course! :-) Eoin. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Eoin Woods, Software Development Group, Bull HN Information Systems, ~ ~ Maxted Road, Hemel Hempstead, Herts HP2 7DZ, UK. ~ ~ Tel : +44 442 232222 x4823 Fax : +44 442 234084 ~ ~ < Eoin.Woods@hemel.bull.co.uk or ...!uunet!ukc!brno!ewoods> ~ ~ < When do we start news group comp.os.emacs ? :-) > ~
rdc30med@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) (01/29/91)
In article <19001@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > I'm considering proposing a REXX news >group if my REXX skills get any better ;-) ] Gee John, g comp.lang.rexx will get it for you right now, no need to propose anything ;-) > -- Mike Dobson, Sys Admin for | Internet: rdc30med@nmrdc1.nmrdc.nnmc.navy.mil nmrdc1.nmrdc.nnmc.navy.mil | UUCP: ...uunet!mimsy!nmrdc1!rdc30med AT&T 3B2/600G Sys V R 3.2.2 | BITNET: dobson@usuhsb or nrd0mxd@vmnmdsc WIN/TCP for 3B2 | MCI-Mail: 377-2719 or 0003772719@mcimail.com
darcy@druid.uucp (D'Arcy J.M. Cain) (01/29/91)
LCDR Michael E. Dobson writes: >In article <19001@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >> I'm considering proposing a REXX news >>group if my REXX skills get any better ;-) ] >Gee John, g comp.lang.rexx will get it for you right now, no need to propose >anything ;-) Maybe he can rename it. ;-> -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | There's no government West Hill, Ontario, Canada | like no government! +1 416 281 6094 |
jfh@rpp386.cactus.org (John F Haugh II) (01/30/91)
In article <1991Jan29.144100.6577@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes: >>> I'm considering proposing a REXX news >>>group if my REXX skills get any better ;-) ] >>Gee John, g comp.lang.rexx will get it for you right now, no need to propose >>anything ;-) > >Maybe he can rename it. ;-> Naw, I was thinking more along the lines of comp.sources.rexx. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "13 of 17 valedictorians in Boston High Schools last spring were immigrants or children of immigrants" -- US News and World Report, May 15, 1990
spaf@cs.purdue.EDU (Gene Spafford) (01/31/91)
In article <3330@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >But one I've been wondering about is, why not an istat(dev, ino, statbuf) >call? Well, ignoring the question of *why* you would want such a call, it is not too difficult to write such a beast that root can use. See, you open the raw device (not the block) associated with the disk, read in the appropriate inode, and.....you get the idea. The kernel filesystem is there to provide you some services, to wit: * device-independent I/O operations * name to location lookup and binding * buffered I/O for better performance * security checks * some consistency control Mucking with direct i-node numbers, even read-only, violates a couple of those ideas, so you have to go through the motions yourself. It isn't all that difficult, but the result is of questionable usefulness. Of course, this only works for local disks. If you are using a remote file systems for the device, have fun :-) -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu phone: (317) 494-7825
hollings@poona.cs.wisc.edu (Jeff Hollingsworth) (02/05/91)
|> Actually, only the network part of the info is truly reliable. |> Someone with a PC could wait until a well known trusted host |> is down for backups or maintenance or whatever, claim to be it, |> and the only way the rest of the net would know is if they cared |> about the ARP mapping between ethernet address and IP address. |> -- |> Many/most Ethernet boards let you set their address too, so you can't even trust that information. The only answer is to use an authentication system like Kerberos. ------------------------------------------------------------------------------- Jeff Hollingsworth Work: (608) 262-6617 Internet: hollings@cs.wisc.edu Home: (608) 256-4839 X.400: <pn=Jeff.Hollingsworth;ou=cs;o=uw-madison;prmd=xnren;c=US>