jbm@uncle.UUCP (John B. Milton) (02/21/89)
Well, I was looking in the manuals (gasp!) and found some interesting things.
I have UNIX version 3.51, and was looking in those manuals. I found an
interesting collection of pages at the end of the "User's Manual Volume I".
Most of them are additions for the news xt/layers commands and new document
processing programs. However, there is a duplicate of the BRK(2) page. I
checked it word for word and the only difference is in the second error
condition about shared memory. The one in Volume II says "... greater than
or equal to the start ...", and the one I just found in the back of Volume I
says "... greater than the start ...". Hmm. I assume since they went to the
trouble of putting a new one in Volume I, that it is the correct one. Any
comments?
Another vote that this is the correct one is the presence of a new section
two call: LOCKING(2). I always wondered if the UNIXpc had this one, but I
never had a pressing need for it, so I never tracked it down. One would think
this would be the first step for a business machine... I also wonder why some
UNIX systems call it LOCKF(). Alex S. Crain, alex@umbc3.UMBC.EDU just posted
a list of the known system call access points, and sure enough, there it is:
#define SYS_LOCKING 67 /* locking() */
Some other ones look interesting. I have seen references, but don't see any
man pages for:
#define SYS_STTY 31 /* stty() */
#define SYS_GTTY 32 /* gtty() */
And why were both of these called utime()?
#define SYS_UTSSYS 57 /* utime() */
#define SYS_UTIME 30 /* utime() */
Hey Alex, where did your info come from anyway?
I assume these extra man pages at the end of Volume I were added at the last
minute. Unfortunatly, (once again probably because they were added at the last
minute) these man pages were printed in such a way that they can't be inserted
where they should be (CHECKMM(1) is on the back of BRK(2)). Hrumph
There is also a new version of COL(1), DIFFMK(1), EQNCHAR(5), KTUNE(7), MM(1),
MM(5), NROFF(1), MPTX(5) and PTX(1). The rest are for new commands.
I just went through Volume II and added "Volume I" to the SEE ALSO section.
The LOCKING page didn't have something else on the back, so I moved that one
between LINK and LSEEK.
I just whipped up a quicky utility to lock a given file. This has it's uses:
Imagine you're hacking away at 3a.m., and you here the click. Oh, I'm being
polled. You check. Aaaahhhhh. That was a disconnect! Aaaaahhh. There's a huge
pile news that just started unbatching...
lock /usr/lib/news/history -z3600 &
Ahhhhh, much better.
I'll post "lock" to unix-pc.sources...
A regular ho-hum user can cause a lot of trouble with this! Consider:
1. lock /usr/adm/cronlog (hang cron)
2. lock /unix, and no more nlist("/unix",)!
3. lock /etc/passwd, and no logins!
4. lock /bin/sh! (this one doesn't work)
5. lock /! (this doesn't work either)
6. lock /tmp/* (good way to make friends)
7. lock /usr/spool/lp/seqfile (no more printing queueing)
8. lock /usr/mail/$LOGNAME (flypaper for anyone who mails you)
9. lock /usr/spool/uucp/SYSLOG (hang all uucicos, thus killing them)
10. lock /usr/spool/uucp/LCK..tty00? MAKE other WAIT for the line.
11. lock /usr/include/stdio.h (everytime I compile, it hangs...)
12. lock /usr/bin/geton.sh (don't let that getty back on)
I have to wonder how many other UNIX systems could be disrupted this way...
John
--
John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu
(614) h:294-4823, w:764-2933; Got any good 74LS503 circuits?gst@gnosys.UUCP (Gary S. Trujillo) (02/22/89)
In article <481@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: > ... > Imagine you're hacking away at 3a.m., and you here the click. Oh, I'm being > polled. You check. Aaaahhhhh. That was a disconnect! Aaaaahhh. There's a huge > pile news that just started unbatching... Of course, if you were using Lenny's "phdaemon", you'd never be in doubt as to which flavor of click you were hearing. :-) But I do take your point about how this utility could help (or hurt) you, and it's a good one. I occasionally take a foray through the manual set, and it can be a real adventure! I have a whole list of things I'd like to try some time. -- Gary S. Trujillo {linus,bbn,m2c}!spdcc!gnosys!gst Somerville, Massachusetts {icus,ima,stech,wjh12}!gnosys!gst
alex@umbc3.UMBC.EDU (Alex S. Crain) (02/22/89)
In article <481@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: >trouble of putting a new one in Volume I, that it is the correct one. Any >comments? I think I remember seeing a note that said their were 3.51 updates to the man pages in the back of Volume 1, or something to that effect, so I guess that you've got the correct versions. I was always sort of pissed off that they didn't print each one on a separate page, so you can't just insert them in the appropriate places (the new tbl(1) has xt(7) on the back). >Another vote that this is the correct one is the presence of a new section >two call: LOCKING(2). I'm glad you mentioned this, I was wondering why there was no man page for it, I was thinking that maybe it didn't work. >Some other ones look interesting. I have seen references, but don't see any >man pages for: > >#define SYS_STTY 31 /* stty() */ >#define SYS_GTTY 32 /* gtty() */ Thats right, no man pages, but check out <sgtty.h> and <sys/ttold.h> I can only guess that something in the software never got ported to the new tty routines, so they left this here for compatability. Seems to work, although I think that its a little incomplete. >And why were both of these called utime()? > >#define SYS_UTSSYS 57 /* utime() */ >#define SYS_UTIME 30 /* utime() */ Because one of them is wrong :-). SYS_UTSSYS is called by uname(), not utime(). (sorry) >Hey Alex, where did your info come from anyway? It was a side effect of my latest project. I'm working on a driver that needs a system call interface, (ioctl() just don't cut it), so I went looking for empty slots in the system call jump table (sysent[], see <sys/systm.h>), which involved disassembling the table. I once needed to verify some calls to syscall() in SBprolog, and it was a pain, so I saved the info this time around. Note that that header file won't compile (multiple definitions of SYS_NODEV), I just put it out there for funzys (sp ?). (although it may turn up in the project that I'm working on, in about 3 months.) -- :alex Alex Crain Systems Programmer alex@umbc3.umbc.edu Univ Md Baltimore County nerwin!alex@umbc3.umbc.edu (NEW DOMAIN)
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (02/22/89)
In article <481@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: > LOCKING(2). I always wondered if the UNIXpc had this one, but I >never had a pressing need for it, so I never tracked it down. One would think >this would be the first step for a business machine... The Unix PC has "real" SysV locking (see fcntl(2) and lockf(3)), so programs should not need locking(2). > I also wonder why some UNIX systems call it LOCKF(). Do they? SysV's lockf() is the posix-compatible locking facility which uses the fcntl F_SETLK facility. I think BSD's lockf is similarly implemented over their "native" locking system call, flock(). I think locking(2) was an early experimental version of SysV locking. It's called BASSLOCKING in the header files, after John Bass, who wrote the code, I beleive. >Alex S. Crain, alex@umbc3.UMBC.EDU just posted >a list of the known system call access points, [ ... ] >Some other ones look interesting. I have seen references, but don't see any >man pages for: > >#define SYS_STTY 31 /* stty() */ >#define SYS_GTTY 32 /* gtty() */ These are old V6 system calls, equivalent to ioctl(TIOC[GS]ETP), but superceded by ioctl(TC[GS]ETA). >And why were both of these called utime()? > >#define SYS_UTSSYS 57 /* utime() */ >#define SYS_UTIME 30 /* utime() */ Probably just a typo. 57 is utssys(), a "catchall" system call used by ustat() and uname(), and on the Unix PC, setuname(). A function number is passed specifying which function is desired, along with the args to that function. 0=uname, 2=ustat, 3=setuname, others=EFAULT. >Hey Alex, where did your info come from anyway? perhaps something like: echo 'sysent,80?xp' | adb /unix /dev/kmem (which will also tell you how many args each call gets). Notice all the slots reserved for "expansion" system calls, such as socket functions. They even already have the nargs field filled in; you could probably guess which was which (or better yet, someone with the TCP/IP software could tell us). >I just whipped up a quicky utility to lock a given file. This has it's uses: >Imagine you're hacking away at 3a.m., and you here the click. Oh, I'm being >polled. You check. Aaaahhhhh. That was a disconnect! Aaaaahhh. There's a huge >pile news that just started unbatching... > >lock /usr/lib/news/history -z3600 & > >Ahhhhh, much better. >A regular ho-hum user can cause a lot of trouble with this! Consider: [ other examples of enforcement mode locking causing problems deleted ] I thought locking() only provided advisory locks. Have you actually tried those examples? I'm not near a Unix PC at the moment so I can't try it or look at the manual. If it really does provide enforcement locking, then yes, it is a serious problem. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!kenobi!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (02/22/89)
>In article <481@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: >> LOCKING(2). I always wondered if the UNIXpc had this one, but I >>A regular ho-hum user can cause a lot of trouble with this! Consider: In article <6034@cbmvax.UUCP> I write: >I thought locking() only provided advisory locks. Have you actually >tried those examples? Yow! I just tried John's locking program and it sure works! "lock /etc/passwd -z3600" pretty much stops the system! I wrote a quicky loadable driver to make the locking() system call require that the affected file be opened with write mode -- at least this is a bit more secure. It's short enough that I figure it's not worth a separate article to unix-pc.sources, so here it is, crossposted. -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!kenobi!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # Install # lkfx.c # This archive created: Tue Feb 21 21:51:59 1989 export PATH; PATH=/bin:$PATH echo shar: extracting "'Install'" '(128 characters)' if test -f 'Install' then echo shar: will not over-write existing file "'Install'" else cat << \SHAR_EOF > 'Install' set -e /etc/masterupd -a init release lkfx make lkfx.o cp lkfx.o /etc/lddrv cd /etc/lddrv ./lddrv -av lkfx echo lkfx >> drivers SHAR_EOF if test 128 -ne "`wc -c < 'Install'`" then echo shar: error transmitting "'Install'" '(should have been 128 characters)' fi chmod +x 'Install' fi # end of overwriting check echo shar: extracting "'lkfx.c'" '(773 characters)' if test -f 'lkfx.c' then echo shar: will not over-write existing file "'lkfx.c'" else cat << \SHAR_EOF > 'lkfx.c' #define KERNEL #include <sys/types.h> #include <sys/conf.h> #include <sys/user.h> #include <sys/file.h> #include <sys/errno.h> #include <sys/systm.h> extern int locking(); #define SYS_locking 67 int fakelocking(); lkfxinit() { if (sysent[SYS_locking].sy_call != locking) { eprintf("lkfxinit: can't install: syscall %d is not `locking'"); u.u_error = EINVAL; return; } sysent[SYS_locking].sy_call = fakelocking; } fakelocking() { register struct a { int fd; int mode; off_t size; } *uap = (struct a *)u.u_ap; struct file *fp; if ((fp = getf(uap->fd)) == NULL) return; if (!(fp->f_flag & FWRITE)) { u.u_error = EACCES; return; } locking(); } lkfxrelease() { sysent[SYS_locking].sy_call = locking; } SHAR_EOF if test 773 -ne "`wc -c < 'lkfx.c'`" then echo shar: error transmitting "'lkfx.c'" '(should have been 773 characters)' fi fi # end of overwriting check # End of shell archive exit 0 -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!kenobi!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
stevens@hsi.UUCP (Richard Stevens) (02/22/89)
In article <6034@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > I thought locking() only provided advisory locks. Have you actually > tried those examples? I'm not near a Unix PC at the moment so I can't > try it or look at the manual. If it really does provide enforcement > locking, then yes, it is a serious problem. Unknown to most, and, of course, undocumented, is the fact that the 3b1 (3.5.1 software) supports both advisory and mandatory locking. Read the first sentence of the lockf(3C) man page - see the reference to chmod(2). Well, they updated the lockf man page, but not the chmod page. You have to go to a real System VR3 manual to see just what to do to get mandatory locking. You enable mandatory locking for a given file by setting its set-group-ID bit on and its group-execute bit off. Then any locks applied to that file are mandatory, not advisory. Otherwise, by default, all locks are advisory only. The real SVR3 ls(1) command was enhanced to look for this, and it notes it (I can't remember just how as my SVR3 manuals aren't handy). Unfortunately, the 3b1's ls never got updated. I've tested the mandatory locking on the 3b1 and it does work. There is definetely a strange combination of Unix versions in the 3b1's Unix system. Richard Stevens Health Systems International, New Haven, CT stevens@hsi.com ... { uunet | yale } ! hsi ! stevens
jbm@uncle.UUCP (John B. Milton) (02/23/89)
In article <6034@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >In article <481@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: [locking()] >The Unix PC has "real" SysV locking (see fcntl(2) and lockf(3)), so >programs should not need locking(2). I feel very stupid, both for not checking section 3 for flock, and for not checking fcntl. I think you're right, with these entry points, locking() does not NEED to be called directly. >I thought locking() only provided advisory locks. Have you actually >tried those examples? I'm not near a Unix PC at the moment so I can't >try it or look at the manual. If it really does provide enforcement >locking, then yes, it is a serious problem. Oh yeah, I tried it. I couldn't stop laughing when I was writing the list of possible "uses". John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:764-2933; Got any good 74LS503 circuits?
jon@jonlab.UUCP (Jon H. LaBadie) (02/23/89)
In article <481@uncle.UUCP>, jbm@uncle.UUCP (John B. Milton) writes: > > Another vote that this is the correct one is the presence of a new section > two call: LOCKING(2). ... > ... I also wonder why some UNIX systems call it LOCKF(). Lockf(3C) is a library interface to whatever the underlying system calls provide for file and record locking. I believe it is also one of the ANSI standard, required routines. Apparently, on the UNIX-PC, the system call is locking(2). On SVR3, the fcntl(2) call is used. The lockf semantics are the same on each system. On lockf(3C), this routine is documented on the UNIX-PC, appears in the libc.a archive, but does not seem to be present in the shared libary ifile. Is this an oversight like the identifier "daylight"? I.e., is it really there, but the identifier is not in the list? The point came up in building netnews software. I knew lockf(3C) was there and wanted netnews to use it. Had to add lines to the makefile to extract lockf.o from the libc.a archive and link it in where needed. It would be nice not to have to do this. -- Jon LaBadie {att, princeton, bcr}!jonlab!jon {att, attmail, bcr}!auxnj!jon
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (02/24/89)
In article <308@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes: >In article <6034@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >> I thought locking() only provided advisory locks. > >Unknown to most, and, of course, undocumented, is the fact that the >3b1 (3.5.1 software) supports both advisory and mandatory locking. That's the fcntl() locking your're talking about; we were talking about the locking() system call. fcntl() locking (what I called "real" SysV locking in the above article) doesn't have the locking() security problem because fcntl() only allows advisory locking unless the file owner marked the file for mandatory locking, and to make a write lock you have to have write permission. You could, however, prevent a database from being updated by putting a read lock on the whole thing. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!kenobi!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
guy@auspex.UUCP (Guy Harris) (02/25/89)
Yow. History time.... >Do they? SysV's lockf() is the posix-compatible locking facility which >uses the fcntl F_SETLK facility. I think BSD's lockf is similarly >implemented over their "native" locking system call, flock(). BSD doesn't *have* a "lockf", and it couldn't be implemented over "flock", anyway, since "flock" can only lock whole files, not regions of files. >I think locking(2) was an early experimental version of SysV locking. It's >called BASSLOCKING in the header files, after John Bass, who wrote the >code, I beleive. John Bass wrote the code at, if I remember correctly, Cal Poly State. He took it with him to Onyx, and also published it in an issue of the USENIX newsletter, ";login:". Various UNIX systems picked it up. I *think* he called the "sysent" entry for it "locking", but I don't remember. "fcntl" locking is a descendant of Bass locking. >>#define SYS_STTY 31 /* stty() */ >>#define SYS_GTTY 32 /* gtty() */ > >These are old V6 system calls, equivalent to ioctl(TIOC[GS]ETP), but >superceded by ioctl(TC[GS]ETA). Yeah, pretty much: Back in UNIX V6, there was no "ioctl" system call. Instead, there were "gtty" and "stty" system calls, that performed the rough equivalent of the TIOCGETP and TIOCSETP "ioctl"s, respectively. V7, as I remember, had "gtty" and "stty" system calls that *literally* performed TIOCGETP and TIOCSETP "ioctl"s; this was presumably for binary compatibility. They were carried into S3 and S5 and company. There were also library routines "gtty" and "stty" that performed the "ioctl"s in question; this was for source compatibility (the idea was presumably not to provide source compatibility through the system calls, in the hope that the system calls could eventually be nuked). UNIX/TS 1.0, which was a mostly-V7 system with some PWB/UNIX stuff in it and was basically the ancestor of S3 and S5, also had no "ioctl" call. Its tty driver was closer to V6's than V7's. I think it may have had an "ioctl" library routine that, when asked to do a TIOCGETP, did a "gtty", and when asked to do a TIOCSETP, did an "stty". The new tty driver, with TC[GS]ETA and company, arrived in S3; it had a "backward compatibility" feature so that it would still support TIOCGETP, TIOCSETP, *et al*. S3 had "ioctl", obviously. The old "gtty" and "stty" system calls were kept around; it appears that in S5R3 the "gtty" and "stty" library routines still invoke the system call, rather than calling "ioctl" with TIOCGETP and TIOCSETP, respectively, so it was probably that way in S3.