0001024: chmod() should be allowed to ignore S_ISVTX

(0003032)
shware_systems (reporter)
2016-01-27 15:51

The exclusion from that clause is intended, iirc (as part of the discussion of Bug #838). As written a system claiming conformance, XSI or as an extension to base POSIX, will not ignore the bit; support for setting it is required if <stat.h> declares it. The circumstances where it can't or shouldn't be set or cleared on the media is accounted for by the EINVAL, EPERM, or EROFS error cases. Whether it gets ignored after being set due to an application having elevated privileges affects other interfaces, not chmod(). The S_ISUID and GID bits are exceptions so an unprivileged application can't elevate a file's privileges if accessed subsequently by a privileged user.

The EINVAL catchall case could also be a 'shall fail' error if the media format does not support recording some of the bits specified to be set, and have the 'may fail' case specifically for if bits are set which do not correspond to any S_* macro.

(0003033)
joerg (reporter)
2016-01-27 16:10

The named systems do not ignore the bit, they just ignore it in case that
the caller does not have the privileges to set it.

It seems that we should permit existing practice since 40 years that exists on certified systems like Solaris or HP-UX.

AIX seems to be the only certified more or less "genetic" UNIX that prints an error message in this case.

(0003034)
shware_systems (reporter)
2016-01-27 16:20

Dunno, longstanding or not, that is what EPERM covers as a 'shall fail' case, for Issue 6 too. If they passed it's a bug in the test suite, it appears.

(0003035)
joerg (reporter)
2016-01-27 16:35
edited on: 2016-01-27 16:36

If this is how UNIX implementation behaved during the past 40 years,
I cannot believe that this could be interpreted as something different
than a POSIX bug.

The intention of POSIX is to describe the behavior of UNIX systems, not
to introduce new rules that are in conflict with existing behavior.

(0003036)
geoffclare (manager)
2016-01-27 16:39
edited on: 2016-01-27 16:40

I think this bug may be mixing up the two different uses of S_ISVTX.

The standard only covers the use of S_ISVTX on directories (XBD 4.2 says "If the S_ISVTX bit is set on a non-directory file, the behavior is unspecified.") Do the systems in question have circumstances where they silently ignore S_ISVTX when changing the mode of a directory, or only of a non-directory file?

(0003037)
shware_systems (reporter)
2016-01-27 17:14

ENOTDIR covers that, also as 'shall fail', as a change from XBD 4 or 5, it seems. If they were 'may fail' then I'd agree the intent was ambiguous, but only EINVAL is now (and possibly shouldn't be, per above). I'm thinking either 1003.1 or SUSV5 was stricter than the other, so despite backwards incompatibility it made it into V6 as an error and no longer ignorable, as the 'safer' choice; but test suite still using test cases that didn't check error being properly returned.

(0003038)
joerg (reporter)
2016-01-27 17:26

The systems in question ignore S_ISVTX for files when the user does not have
the needed privileges to set the bit. For directories S_ISVTX is not ignored.

(0003039)
Clausecker (reporter)
2016-01-27 17:40

At least one system (OpenBSD) consequently ignores attempts to set S_ISVTX, even if attempted by the superuser.

(0003040)
schwarze (reporter)
2016-01-27 18:05

Re: 0003039

Clausecker, testing on OpenBSD-current, i cannot reproduce. When calling chmod(..., S_ISVTX) on a directory, i get success, no change to errno, and the directory ends up with mode 01000. On a regular file, i get failure, errno set to EFTYPE, and no change to the file modes. So far for a normal user. As root, the same for a directory, but i get success, no change to errno, and mode 01000 even for a regular file.

On first sight, i don't see any case where anything is silently ignored.

(0003041)
joerg (reporter)
2016-01-27 18:10

So OpenBSD behaves similar to AIX, except that it uses an illegal errno.
The value EFTYPE was introduced on *BSD in 1990 for content errors in
/etc/fstab or in the disk partitioning.

(0003042)
Clausecker (reporter)
2016-01-27 18:15

schwarze, I'm sorry for my incorrect claim. The following is documented in the OpenBSD manpage:

If mode ISVTX (the sticky bit) is set on a file, it is ignored.

I trusted the manpage but testing confirms your report. It seems like the manpage is incorrect.

(0003043)
shware_systems (reporter)
2016-01-27 21:11

That would be a case where it got set in a non-directory on-disk descriptor, as 'file', by a means other than a non-priveleged chmod(). That the interface allows it in superuser mode could be considered a bug left over from ISTXT using the same bit position in earlier versions, perhaps, but su stuff out of scope for POSIX. I'd think the interfaces that test for the bits presence or absence would be expected to ignore it those regular files as irrelevant.

(0003044)
schwarze (reporter)
2016-01-27 21:17

Re: 0003042

Clausecker, the manual isn't incorrect, the wording is merely slightly ambiguous. The intended meaning is *not* "the attempt to set it is ignored and the bit won't be set", but the intended meaning is "later on, the fact that the bit is now set will be ignored by the rest of the system, it doesn't matter whether or not the bit is set on a file (as opposed to on a directory)". That becomes clearer from the context, in particular the following sentence in that manual page. But this is getting off-topic, if i understand 0003036 correctly, POSIX only specifies the effect of S_ISVTX for directories, so it shouldn't matter to POSIX what some operating system does with it when applied to regular files.

Yes, throwing EFTYPE looks slightly suspicious, i'm not completely convinced that's ideal, but at worst, that's a case of non-conformance in our code. I'm not sure it should have any bearing on what the standard should require.

(0003045)
philip-guenther (reporter)
2016-01-27 23:25

A comparison of ufs/ufs_vnops.c:chmod1() in 4.3BSD-Reno and Net2 shows the transition from silently suppressing S_ISVTX on non-directories to return EFTYPE happened between them, in late 1990 early 1991. Anyone have the SCCS files to see what Kirk's commit message was? ;-)

With that behavior in Net2 and then 4.4BSD, it of course ended up in all the later BSDs, Free, Net, and Open.

(0003046)
dickey (reporter)
2016-01-27 23:56

You may be thinking of this change:

https://github.com/jonathangray/csrg/blob/3f86276982ac68fb117ead4a73acaac8c6ca0485/sys/ufs/ufs/ufs_vnops.c [^]

(0003047)
dickey (reporter)
2016-01-27 23:58

Better link:

https://github.com/jonathangray/csrg/commit/4fbceac9fb3bbbffba76bbc1989393837c901c9e#diff-30aeaac7b80c2a09d2bb3013eaf478a9 [^]

(0003048)
joerg (reporter)
2016-01-28 11:22
edited on: 2016-01-28 11:26

Here is the delta message retrieved via "SCCS -R log" on the whole project:

Fri Dec 14 12:40:40 1990 bostic
        * ./sys/ufs/ffs/ffs_vnops.c 7.48
        * ./sys/ufs/ffs/ufs_vnops.c 7.48
        * ./sys/ufs/lfs/lfs_vnops.c 7.48
        * ./sys/ufs/ufs/ufs_vnops.c 7.48
          fail if try to set VTX on file not of type directory, or GID and not
          member of the group

So it was not Kirk but rather Keith Bostic, the same person who introduced the error code.

Here is the annotated code sniplet retrived via "sccs get -p -A -m -r7.48":

4.21    root            82/03/18        /* 
4.42    sam             82/11/13         * Change the mode on a file. 
4.42    sam             82/11/13         * Inode must be locked before calling. 
4.42    sam             82/11/13         */ 
7.7     mckusick        89/05/09        chmod1(vp, mode, cred) 
7.7     mckusick        89/05/09                register struct vnode *vp; 
4.32    sam             82/08/10                register int mode; 
7.7     mckusick        89/05/09                struct ucred *cred; 
4.32    sam             82/08/10        { 
7.7     mckusick        89/05/09                register struct inode *ip = VTOI(vp); 
7.9     mckusick        89/05/09                int error; 
4.35    root            82/08/24         
7.9     mckusick        89/05/09                if (cred->cr_uid != ip->i_uid && 
7.9     mckusick        89/05/09                    (error = suser(cred, &u.u_acflag))) 
7.9     mckusick        89/05/09                        return (error); 
7.7     mckusick        89/05/09                if (cred->cr_uid) { 
7.48    bostic          90/12/14                        if (vp->v_type != VDIR && mode &a
mp; ISVTX) 
7.48    bostic          90/12/14                                return (EFTYPE); 
7.48    bostic          90/12/14                        if (!groupmember(ip->i_gid, cred) &&a
mp; mode & ISGID) 
7.48    bostic          90/12/14                                return (EPERM); 
4.28    root            82/07/15                } 
7.48    bostic          90/12/14                ip->i_mode &= ~07777; 
7.7     mckusick        89/05/09                ip->i_mode |= mode & 07777; 
4.21    root            82/03/18                ip->i_flag |= ICHG; 
7.7     mckusick        89/05/09                if ((vp->v_flag & VTEXT) && (ip->i
_mode & ISVTX) == 0) 
7.47    mckusick        90/12/05                        (void) vnode_pager_uncache(vp); 
6.18    mckusick        85/05/22                return (0); 
4.18    wnj             82/02/27        }

(0003055)
shware_systems (reporter)
2016-01-28 19:00

While use of EFTYPE is allowed as an extension, I think EINVAL is what people just reading the standard might expect, as an invalid bit for non-dir file types.

(0003056)
Clausecker (reporter)
2016-01-28 19:05

shware_systems, I don't believe EINVAL is appropriate. Setting S_ISVTX on a non-directory is not an invalid operation. It is merely not allowed to do without appropriate permissions. The error code should be EPERM as the operation failed due to lack of permissions.

(0003495)
Don Cragun (manager)
2016-11-17 17:37

If I create an archive on a non-BSD system containing regular files with the S_ISVTX bit set and try to unarchive those files and preserve file modes on a BSD system, it seems from the discussion in these notes that the file extraction will fail. But on other systems that don't support the S_ISVTX bit on regular files, the file would be extracted successfully with the sticky bit silently ignored.

Is this difference viewed as a "feature" or a "bug" on BSD systems?

(0003497)
GarrettWollman (reporter)
2016-11-17 21:24

Documented behavior.

     [EFTYPE] The effective user ID is not the super-user, the mode
                        includes the sticky bit (S_ISVTX), and path does not
                        refer to a directory.

Note that you can still set the sticky bit with appropriate privilege, so the argument that [EPERM] would be a better error to use is legitimate, but contrary to history. [EFTYPE] has been documented since 1997.

(0003498)
Don Cragun (manager)
2016-11-17 22:20

Re: Note: 0003497
I understand that the behavior is documented. I was asking in Note: 0003495 whether users find that documented behavior to be useful or to be a hindrance in doing what they need to do to get their jobs done.

(0003499)
GarrettWollman (reporter)
2016-11-17 23:06

I think you would have to poll the users to find out. This is not a situation that comes up with any frequency, and my vague recollection is that setting the sticky bit on an executable (in the historical usage) always required appropriate privilege. Near as I can tell, there has never been a single bug report filed regarding this behavior.

Also note that FreeBSD does not claim to implement the XSI option, so a bug report about this might be closed with a WONTFIX. I did not see any such reports, however. (Very early on there was one bug report -- about [EFTYPE] not being documented, not about the actual behavior.)

(0003506)
geoffclare (manager)
2016-12-01 16:19
edited on: 2016-12-01 16:23

Interpretation response
------------------------
The standard states the requirements for chmod(), and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

Rationale:
-------------
Existing practice on some systems is to ignore S_ISVTX for non-directory files in non-privileged processes.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Change lines 22352–22353 from:

Additional implementation-defined restrictions may cause the S_ISUID and S_ISGID bits in mode to be ignored.

to:

Additional implementation-defined restrictions may cause the S_ISUID and S_ISGID bits in mode to be ignored, [XSI]and may cause the S_ISVTX bit in mode to be ignored for non-directory files[/XSI].

(0003507)
geoffclare (manager)
2016-12-01 16:21

Note that the change in Note: 0003506 still allows the BSD behaviour, since ignoring S_ISVTX is optional.

(0003515)
ajosey (manager)
2016-12-15 18:08

Interpretation proposed: 15 Dec 2016

(0003545)
ajosey (manager)
2017-01-18 15:22

Interpretation Approved: 18 Jan 2017

Notes
(0003032) shware_systems (reporter) 2016-01-27 15:51	The exclusion from that clause is intended, iirc (as part of the discussion of Bug #838). As written a system claiming conformance, XSI or as an extension to base POSIX, will not ignore the bit; support for setting it is required if <stat.h> declares it. The circumstances where it can't or shouldn't be set or cleared on the media is accounted for by the EINVAL, EPERM, or EROFS error cases. Whether it gets ignored after being set due to an application having elevated privileges affects other interfaces, not chmod(). The S_ISUID and GID bits are exceptions so an unprivileged application can't elevate a file's privileges if accessed subsequently by a privileged user. The EINVAL catchall case could also be a 'shall fail' error if the media format does not support recording some of the bits specified to be set, and have the 'may fail' case specifically for if bits are set which do not correspond to any S_* macro.

(0003033) joerg (reporter) 2016-01-27 16:10	The named systems do not ignore the bit, they just ignore it in case that the caller does not have the privileges to set it. It seems that we should permit existing practice since 40 years that exists on certified systems like Solaris or HP-UX. AIX seems to be the only certified more or less "genetic" UNIX that prints an error message in this case.

(0003034) shware_systems (reporter) 2016-01-27 16:20	Dunno, longstanding or not, that is what EPERM covers as a 'shall fail' case, for Issue 6 too. If they passed it's a bug in the test suite, it appears.

(0003035) joerg (reporter) 2016-01-27 16:35 edited on: 2016-01-27 16:36	If this is how UNIX implementation behaved during the past 40 years, I cannot believe that this could be interpreted as something different than a POSIX bug. The intention of POSIX is to describe the behavior of UNIX systems, not to introduce new rules that are in conflict with existing behavior.

(0003036) geoffclare (manager) 2016-01-27 16:39 edited on: 2016-01-27 16:40	I think this bug may be mixing up the two different uses of S_ISVTX. The standard only covers the use of S_ISVTX on directories (XBD 4.2 says "If the S_ISVTX bit is set on a non-directory file, the behavior is unspecified.") Do the systems in question have circumstances where they silently ignore S_ISVTX when changing the mode of a directory, or only of a non-directory file?

(0003037) shware_systems (reporter) 2016-01-27 17:14	ENOTDIR covers that, also as 'shall fail', as a change from XBD 4 or 5, it seems. If they were 'may fail' then I'd agree the intent was ambiguous, but only EINVAL is now (and possibly shouldn't be, per above). I'm thinking either 1003.1 or SUSV5 was stricter than the other, so despite backwards incompatibility it made it into V6 as an error and no longer ignorable, as the 'safer' choice; but test suite still using test cases that didn't check error being properly returned.

(0003038) joerg (reporter) 2016-01-27 17:26	The systems in question ignore S_ISVTX for files when the user does not have the needed privileges to set the bit. For directories S_ISVTX is not ignored.

(0003039) Clausecker (reporter) 2016-01-27 17:40	At least one system (OpenBSD) consequently ignores attempts to set S_ISVTX, even if attempted by the superuser.

(0003040) schwarze (reporter) 2016-01-27 18:05	Re: 0003039 Clausecker, testing on OpenBSD-current, i cannot reproduce. When calling chmod(..., S_ISVTX) on a directory, i get success, no change to errno, and the directory ends up with mode 01000. On a regular file, i get failure, errno set to EFTYPE, and no change to the file modes. So far for a normal user. As root, the same for a directory, but i get success, no change to errno, and mode 01000 even for a regular file. On first sight, i don't see any case where anything is silently ignored.

(0003041) joerg (reporter) 2016-01-27 18:10	So OpenBSD behaves similar to AIX, except that it uses an illegal errno. The value EFTYPE was introduced on *BSD in 1990 for content errors in /etc/fstab or in the disk partitioning.

(0003042) Clausecker (reporter) 2016-01-27 18:15	schwarze, I'm sorry for my incorrect claim. The following is documented in the OpenBSD manpage: If mode ISVTX (the sticky bit) is set on a file, it is ignored. I trusted the manpage but testing confirms your report. It seems like the manpage is incorrect.

(0003043) shware_systems (reporter) 2016-01-27 21:11	That would be a case where it got set in a non-directory on-disk descriptor, as 'file', by a means other than a non-priveleged chmod(). That the interface allows it in superuser mode could be considered a bug left over from ISTXT using the same bit position in earlier versions, perhaps, but su stuff out of scope for POSIX. I'd think the interfaces that test for the bits presence or absence would be expected to ignore it those regular files as irrelevant.

(0003044) schwarze (reporter) 2016-01-27 21:17	Re: 0003042 Clausecker, the manual isn't incorrect, the wording is merely slightly ambiguous. The intended meaning is not "the attempt to set it is ignored and the bit won't be set", but the intended meaning is "later on, the fact that the bit is now set will be ignored by the rest of the system, it doesn't matter whether or not the bit is set on a file (as opposed to on a directory)". That becomes clearer from the context, in particular the following sentence in that manual page. But this is getting off-topic, if i understand 0003036 correctly, POSIX only specifies the effect of S_ISVTX for directories, so it shouldn't matter to POSIX what some operating system does with it when applied to regular files. Yes, throwing EFTYPE looks slightly suspicious, i'm not completely convinced that's ideal, but at worst, that's a case of non-conformance in our code. I'm not sure it should have any bearing on what the standard should require.

(0003045) philip-guenther (reporter) 2016-01-27 23:25	A comparison of ufs/ufs_vnops.c:chmod1() in 4.3BSD-Reno and Net2 shows the transition from silently suppressing S_ISVTX on non-directories to return EFTYPE happened between them, in late 1990 early 1991. Anyone have the SCCS files to see what Kirk's commit message was? ;-) With that behavior in Net2 and then 4.4BSD, it of course ended up in all the later BSDs, Free, Net, and Open.

(0003046) dickey (reporter) 2016-01-27 23:56	You may be thinking of this change: https://github.com/jonathangray/csrg/blob/3f86276982ac68fb117ead4a73acaac8c6ca0485/sys/ufs/ufs/ufs_vnops.c [^]

(0003047) dickey (reporter) 2016-01-27 23:58	Better link: https://github.com/jonathangray/csrg/commit/4fbceac9fb3bbbffba76bbc1989393837c901c9e#diff-30aeaac7b80c2a09d2bb3013eaf478a9 [^]

(0003048) joerg (reporter) 2016-01-28 11:22 edited on: 2016-01-28 11:26	Here is the delta message retrieved via "SCCS -R log" on the whole project: Fri Dec 14 12:40:40 1990 bostic * ./sys/ufs/ffs/ffs_vnops.c 7.48 * ./sys/ufs/ffs/ufs_vnops.c 7.48 * ./sys/ufs/lfs/lfs_vnops.c 7.48 * ./sys/ufs/ufs/ufs_vnops.c 7.48 fail if try to set VTX on file not of type directory, or GID and not member of the group So it was not Kirk but rather Keith Bostic, the same person who introduced the error code. Here is the annotated code sniplet retrived via "sccs get -p -A -m -r7.48": 4.21 root 82/03/18 /* 4.42 sam 82/11/13 * Change the mode on a file. 4.42 sam 82/11/13 * Inode must be locked before calling. 4.42 sam 82/11/13 / 7.7 mckusick 89/05/09 chmod1(vp, mode, cred) 7.7 mckusick 89/05/09 register struct vnode vp; 4.32 sam 82/08/10 register int mode; 7.7 mckusick 89/05/09 struct ucred cred; 4.32 sam 82/08/10 { 7.7 mckusick 89/05/09 register struct inode ip = VTOI(vp); 7.9 mckusick 89/05/09 int error; 4.35 root 82/08/24 7.9 mckusick 89/05/09 if (cred->cr_uid != ip->i_uid && 7.9 mckusick 89/05/09 (error = suser(cred, &u.u_acflag))) 7.9 mckusick 89/05/09 return (error); 7.7 mckusick 89/05/09 if (cred->cr_uid) { 7.48 bostic 90/12/14 if (vp->v_type != VDIR && mode &a mp; ISVTX) 7.48 bostic 90/12/14 return (EFTYPE); 7.48 bostic 90/12/14 if (!groupmember(ip->i_gid, cred) &&a mp; mode & ISGID) 7.48 bostic 90/12/14 return (EPERM); 4.28 root 82/07/15 } 7.48 bostic 90/12/14 ip->i_mode &= ~07777; 7.7 mckusick 89/05/09 ip->i_mode \|= mode & 07777; 4.21 root 82/03/18 ip->i_flag \|= ICHG; 7.7 mckusick 89/05/09 if ((vp->v_flag & VTEXT) && (ip->i _mode & ISVTX) == 0) 7.47 mckusick 90/12/05 (void) vnode_pager_uncache(vp); 6.18 mckusick 85/05/22 return (0); 4.18 wnj 82/02/27 }

(0003055) shware_systems (reporter) 2016-01-28 19:00	While use of EFTYPE is allowed as an extension, I think EINVAL is what people just reading the standard might expect, as an invalid bit for non-dir file types.

(0003056) Clausecker (reporter) 2016-01-28 19:05	shware_systems, I don't believe EINVAL is appropriate. Setting S_ISVTX on a non-directory is not an invalid operation. It is merely not allowed to do without appropriate permissions. The error code should be EPERM as the operation failed due to lack of permissions.

(0003495) Don Cragun (manager) 2016-11-17 17:37	If I create an archive on a non-BSD system containing regular files with the S_ISVTX bit set and try to unarchive those files and preserve file modes on a BSD system, it seems from the discussion in these notes that the file extraction will fail. But on other systems that don't support the S_ISVTX bit on regular files, the file would be extracted successfully with the sticky bit silently ignored. Is this difference viewed as a "feature" or a "bug" on BSD systems?

(0003497) GarrettWollman (reporter) 2016-11-17 21:24	Documented behavior. [EFTYPE] The effective user ID is not the super-user, the mode includes the sticky bit (S_ISVTX), and path does not refer to a directory. Note that you can still set the sticky bit with appropriate privilege, so the argument that [EPERM] would be a better error to use is legitimate, but contrary to history. [EFTYPE] has been documented since 1997.

(0003498) Don Cragun (manager) 2016-11-17 22:20	Re: Note: 0003497 I understand that the behavior is documented. I was asking in Note: 0003495 whether users find that documented behavior to be useful or to be a hindrance in doing what they need to do to get their jobs done.

(0003499) GarrettWollman (reporter) 2016-11-17 23:06	I think you would have to poll the users to find out. This is not a situation that comes up with any frequency, and my vague recollection is that setting the sticky bit on an executable (in the historical usage) always required appropriate privilege. Near as I can tell, there has never been a single bug report filed regarding this behavior. Also note that FreeBSD does not claim to implement the XSI option, so a bug report about this might be closed with a WONTFIX. I did not see any such reports, however. (Very early on there was one bug report -- about [EFTYPE] not being documented, not about the actual behavior.)

(0003506) geoffclare (manager) 2016-12-01 16:19 edited on: 2016-12-01 16:23	Interpretation response ------------------------ The standard states the requirements for chmod(), and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- Existing practice on some systems is to ignore S_ISVTX for non-directory files in non-privileged processes. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Change lines 22352–22353 from: Additional implementation-defined restrictions may cause the S_ISUID and S_ISGID bits in mode to be ignored. to: Additional implementation-defined restrictions may cause the S_ISUID and S_ISGID bits in mode to be ignored, [XSI]and may cause the S_ISVTX bit in mode to be ignored for non-directory files[/XSI].

(0003507) geoffclare (manager) 2016-12-01 16:21	Note that the change in Note: 0003506 still allows the BSD behaviour, since ignoring S_ISVTX is optional.

(0003515) ajosey (manager) 2016-12-15 18:08	Interpretation proposed: 15 Dec 2016

(0003545) ajosey (manager) 2017-01-18 15:22	Interpretation Approved: 18 Jan 2017

Issue History
Date Modified	Username	Field	Change
2016-01-26 20:31	Clausecker	New Issue
2016-01-26 20:31	Clausecker	Name	=> Robert Clausecker
2016-01-26 20:31	Clausecker	Organization	=> Fraunhofer FOKUS
2016-01-26 20:31	Clausecker	Section	=> chmod()
2016-01-26 20:31	Clausecker	Page Number	=> 660
2016-01-26 20:31	Clausecker	Line Number	=> 22352–22353
2016-01-27 15:51	shware_systems	Note Added: 0003032
2016-01-27 16:10	joerg	Note Added: 0003033
2016-01-27 16:20	shware_systems	Note Added: 0003034
2016-01-27 16:35	joerg	Note Added: 0003035
2016-01-27 16:36	joerg	Note Edited: 0003035
2016-01-27 16:39	geoffclare	Note Added: 0003036
2016-01-27 16:40	geoffclare	Note Edited: 0003036
2016-01-27 17:14	shware_systems	Note Added: 0003037
2016-01-27 17:26	joerg	Note Added: 0003038
2016-01-27 17:40	Clausecker	Note Added: 0003039
2016-01-27 18:05	schwarze	Note Added: 0003040
2016-01-27 18:10	joerg	Note Added: 0003041
2016-01-27 18:15	Clausecker	Note Added: 0003042
2016-01-27 21:11	shware_systems	Note Added: 0003043
2016-01-27 21:17	schwarze	Note Added: 0003044
2016-01-27 23:25	philip-guenther	Note Added: 0003045
2016-01-27 23:56	dickey	Note Added: 0003046
2016-01-27 23:58	dickey	Note Added: 0003047
2016-01-28 11:22	joerg	Note Added: 0003048
2016-01-28 11:23	joerg	Note Edited: 0003048
2016-01-28 11:24	joerg	Note Edited: 0003048
2016-01-28 11:26	joerg	Note Edited: 0003048
2016-01-28 11:26	joerg	Note Edited: 0003048
2016-01-28 19:00	shware_systems	Note Added: 0003055
2016-01-28 19:05	Clausecker	Note Added: 0003056
2016-11-17 17:37	Don Cragun	Note Added: 0003495
2016-11-17 21:24	GarrettWollman	Note Added: 0003497
2016-11-17 22:20	Don Cragun	Note Added: 0003498
2016-11-17 23:06	GarrettWollman	Note Added: 0003499
2016-12-01 16:19	geoffclare	Note Added: 0003506
2016-12-01 16:21	geoffclare	Interp Status	=> Pending
2016-12-01 16:21	geoffclare	Final Accepted Text	=> Note: 0003506
2016-12-01 16:21	geoffclare	Note Added: 0003507
2016-12-01 16:21	geoffclare	Status	New => Interpretation Required
2016-12-01 16:21	geoffclare	Resolution	Open => Accepted As Marked
2016-12-01 16:21	geoffclare	Tag Attached: tc3-2008
2016-12-01 16:23	geoffclare	Note Edited: 0003506
2016-12-15 18:08	ajosey	Interp Status	Pending => Proposed
2016-12-15 18:08	ajosey	Note Added: 0003515
2017-01-18 15:22	ajosey	Interp Status	Proposed => Approved
2017-01-18 15:22	ajosey	Note Added: 0003545
2019-10-21 14:10	geoffclare	Status	Interpretation Required => Applied

Relationships

Aardvark Mark IV