rjd@attibr.UUCP (Robert J. Diamond) (11/18/88)
When at at job is created on SVR3.x, here is the resulting files that are created: -r-Sr-lr-- 1 root other 571 Nov 17 18:00 595897200.a -r-Sr-lr-- 1 root other 865 Nov 18 09:45 595918800.a What does the 'l' mean in the group execute permission field? I couldn't find it in the User Reference manual. -- Robert Jon Diamond | AT&T | <backbone>!ulysses!attibr!rjd International Operations Support | attmail: rdiamond 1300 Mt. Kemble Avenue, Basking Ridge, NJ | (201) 953-7650
dmt@ptsfa.PacBell.COM (Dave Turner) (11/19/88)
In article <71@attibr.UUCP> rjd@attibr.UUCP (Robert J. Diamond) writes: >When at at job is created on SVR3.x, here is the resulting files that >are created: > >-r-Sr-lr-- 1 root other 571 Nov 17 18:00 595897200.a >-r-Sr-lr-- 1 root other 865 Nov 18 09:45 595918800.a > >What does the 'l' mean in the group execute permission field? I couldn't >find it in the User Reference manual. According to the AT&T 3B4000 & 3B15 Computer UNIX System V User's and System Administrator's Reference Manual Section 1 (305-205), the l in the group execution slot means that mandatory locking will occur during access. "Mandatory file and record locking (l) refers to a file's ability to have its reading or writing permissions locked while a program is accessing that file. It is not possible to permit group execution and enable a file to be locked on execution at the same time." From chmod(1) "In the case of the sequence of group permissions, l may occupy the third position. l refers to mandatory file and record locking. This permission describes a file's ability to allow other files to lock its reading or writing permissions during access." From ls(1) -- Dave Turner 415/542-1299 {att,bellcore,sun,ames,pyramid}!pacbell!dmt
guy@auspex.UUCP (Guy Harris) (11/22/88)
>>When at at job is created on SVR3.x, here is the resulting files that >>are created: >> >>-r-Sr-lr-- 1 root other 571 Nov 17 18:00 595897200.a >>-r-Sr-lr-- 1 root other 865 Nov 18 09:45 595918800.a >> >>What does the 'l' mean in the group execute permission field? >According to the AT&T 3B4000 & 3B15 Computer UNIX System V User's and >System Administrator's Reference Manual Section 1 (305-205), >the l in the group execution slot means that mandatory locking will >occur during access. Yes, but what it *really* means in some sense is "the set-GID bit is set but the group execute bit isn't set." There's no "mandatory locking" permission bit; they ripped off the set-GID bit, saying it means "mandatory locking" when the group execute bit isn't set. The "S" means "set-UID bit is set, user execute bit isn't set"; "r-Sr-lr--" means "the only permission bits that are set are all three read bits and the set-UID and set-GID bits". "at" turns them on so that it can detect some clever dick who creates an "at" job and gives it away to user "root", attempting to trick "at" into running it as "root"; the kernel turns the set-UID bit off when the ownership is changed (by anybody but "root"), and "at" says "Fraud!" when it detects that the magic Seal of Approval bits aren't set.
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (11/23/88)
> >>-r-Sr-lr-- 1 root other 865 Nov 18 09:45 595918800.a > >> > >According to the AT&T 3B4000 & 3B15 Computer UNIX System V User's and > >System Administrator's Reference Manual Section 1 (305-205), > >the l in the group execution slot means that mandatory locking will > >occur during access. Can someone explain "mandatory locking" as used here. I find that Sys V.3 allows two processes to open and write to a file with 'l' permisssions. -- Jon Zeeff A month ago I modified broke into umix!b-tech!zeeff your system and modified your kernel. zeeff@b-tech.ann-arbor.mi.us Have you proved me wrong?
friedl@vsi.COM (Stephen J. Friedl) (11/25/88)
In article <4945@b-tech.ann-arbor.mi.us>, zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > Can someone explain "mandatory locking" as used here. I find that Sys V.3 > allows two processes to open and write to a file with 'l' permisssions. There are two kinds of locks supported by most versions of UNIX (Sys V, at least), advisory and mandatory. An advisory lock is a Post-it(tm) put on a record saying "please keep away", and a program is free to ignore it. It requires that two programs dealing with a file cooperate by always querying the locks first, and an uncooperative or buggy program can read or write any record. Mandatory (aka `enforcement-mode') locks, on the other hand, live inside the read/write mechanism. If a file has the mandatory lock bit set in the mode, locking a record will prevent any access to that record by any program even if this other program has no knowledge of locks. I'm speculating on this part, but I guess that setting the `l' mode is required because the vast majority of programs don't use locking, and the overhead required on each read/write call is probably too much. Setting the lock bit probably enables this checking. -- Steve Friedl V-Systems, Inc. +1 714 545 6442 3B2-kind-of-guy friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl ------------Nancy Reagan on climaxes: "Just say moan!"------------- :wq!
guy@auspex.UUCP (Guy Harris) (11/25/88)
>Can someone explain "mandatory locking" as used here. I find that Sys V.3 >allows two processes to open and write to a file with 'l' permisssions. As it is supposed to. "Mandatory locking" merely means that if you use "fcntl" or "lockf" to lock a region of the file, attempts to write the locked region of the file will block until the lock is released, and if the lock is also supposed to block attempts to read that region, it will do that as well.
henry@utzoo.uucp (Henry Spencer) (11/26/88)
In article <951@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >I'm speculating on this part, but I guess that setting the `l' mode >is required because the vast majority of programs don't use locking, >and the overhead required on each read/write call is probably too much. Consider a program that mandatory-locks /etc/passwd and then sleeps forever. Antisocial, no? So mandatory locking is available only on files that are explicitly marked as "okay to lock". -- Sendmail is a bug, | Henry Spencer at U of Toronto Zoology not a feature. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
guy@auspex.UUCP (Guy Harris) (11/26/88)
>Consider a program that mandatory-locks /etc/passwd and then sleeps forever. >Antisocial, no? So mandatory locking is available only on files that are >explicitly marked as "okay to lock". Well, actually, in order to lock out reads, you have to establish a write lock on the region in question, and to establish a write lock you need to have a file descriptor open for writing; if you have a file descriptor for "/etc/passwd" that's open for writing, you can do much more antisocial things than just locking it forever.... In AT&T's documentation, they appear to recommend that you not use mandatory locking because there's extra overhead on every read or write performed, since before every read or write the system has to check for locks. They also note that mandatory locking is not always necessary nor sufficient.
henry@utzoo.uucp (Henry Spencer) (11/30/88)
In article <516@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >>Consider a program that mandatory-locks /etc/passwd and then sleeps forever. >>... >Well, actually, in order to lock out reads, you have to establish a >write lock on the region in question, and to establish a write lock you >need to have a file descriptor open for writing... Hmm, guess I should have read the documentation! :-) At at least one point in the past, for at least one of the locking schemes (/usr/group?), locking /etc/passwd *was* a problem and hence the 'l' bit. >In AT&T's documentation, they appear to recommend that you not use >mandatory locking because there's extra overhead on every read or write >performed... One can always argue that a more efficient implementation could largely fix this. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
allbery@ncoast.UUCP (Brandon S. Allbery) (12/01/88)
As quoted from <951@vsi.COM> by friedl@vsi.COM (Stephen J. Friedl): +--------------- > (re: the "l" mode bit in SVR3.2 and mandatory/advisory file locking) | | I'm speculating on this part, but I guess that setting the `l' mode | is required because the vast majority of programs don't use locking, | and the overhead required on each read/write call is probably too much. | Setting the lock bit probably enables this checking. +--------------- No, it's because advisory file locking is the SVR3 standard, but mandatory file locking was in Xenix. So UNIX apps use standard file locking and migrated Xenix apps should set the "l" bit in order to work correctly. I dunno, the whole thing seems a bit klugey to me. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.