Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001274 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Editorial Omission 2019-07-28 10:42 2024-06-11 09:08
Reporter dannyniu View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name DannyNiu/NJF
Organization Individual
User Reference
Section <sys/types.h> header
Page Number 402-405
Line Number 13652-13746
Interp Status ---
Final Accepted Text Note: 0004556
Summary 0001274: pid_t must fit in an int for definition of fcntl to be consistent.
Description As the return type of fcntl is int, and F_GETOWN returns the process (-group) receiving SIGIO and SIGURG signals, pid_t must fit into an int for the fcntl function to be consistent.

However, there's not yet any explicit mention of this requirement in the standard text.
Desired Action After line 13731, insert:

the width of pid_t shall be no greater than the width of int.
Tags issue8
Attached Files

- Relationships
related to 0001670Closed Issue 8 drafts F_GETOWN_EX and F_SETOWN_EX missing from fcntl() RETURN VALUE 

-  Notes
(0004496)
jilles (reporter)
2019-07-28 13:49

There is indeed an inconsistency here, but it could be resolved in various ways, depending on compatibility issues and risk of weirdnix implementations:

* Only require that actual process IDs fit in an int, without requiring anything new about the type pid_t.
* Require "the width of pid_t shall be no greater than the width of int".
* Require that the range of pid_t be equal to the range of int.
* Require that pid_t be a typedef for int.

Types smaller than int may have surprising behaviour due to integer promotion, which suggests not going out of our way to allow them.

In hindsight, it may have made more sense to define a new function instead of standardizing the existing fcntl() (compare tcgetpgrp()), but I don't think it is useful to add such a function now.
(0004497)
shware_systems (reporter)
2019-07-29 00:52

The requirement currently is "the width of pid_t shall be no greater than the width of intmax_t.", with the phrasing of <sys/types.h>, and limiting it to int is a potential breaking change. As a future consideration for implementations this phrasing is appropriate for <sys/types.h>, from a speed, packing, or alignment perspective, and should not be modified how this bug report requests, in my opinion.

The aspect of fcntl() that deals with this currently is it is required to set EOVERFLOW in errno if the process ID value is larger than INT_MAX or smaller than INT_MIN, per line 27934. From an 'are our bases covered?' perspective this is adequate. Fixing the interface so the possibility of this error is precluded requires invention, as in an F_GETPID variation that stores the result in an va_arg value cast as (pid_t *), not return it as cast to an int. The return value then could be a flag that the ID is valid or zero, or to check errno for other error conditions, such as fd not referring to a socket. Such a variation I do see as useful, and should be easy to implement.
(0004498)
geoffclare (manager)
2019-07-29 09:08

There is no problem with F_GETOWN here because the value to be returned is guaranteed to be able to fit in an int. This is because it is set via an int argument passed to fcntl() with F_SETOWN. (Okay, there might be an extension that could be used to set it to a larger value, but then there would be an equivalent extension to query it as well.)

So the only real problem I see is that it is not possible for a process with a PID greater than INT_MAX or a process group with a PGID greater than INT_MAX+1 to be set to receive SIGURG signals (without using an extension).

One solution would be to require that process IDs are always <= INT_MAX. Another would be to make F_SETOWN and F_GETOWN obsolescent and warn about the problem in APPLICATION USAGE.

There is certainly no need to alter the requirements about how pid_t can be defined.
(0004524)
eblake (manager)
2019-08-15 16:37

Linux fcntl has F_SETOWN_EX/F_GETOWN_EX that takes a pointer to:
                  struct f_owner_ex {
                      int type;
                      pid_t pid;
                  };
as a way that would allow access to pid_t larger than int (although at the moment pid_t on Linux is still int)
(0004525)
shware_systems (reporter)
2019-08-15 16:52

Re: 4524
Do you have a kernel.org URL to the header where that is typedef'd, or the man page showing that?
(0004526)
eblake (manager)
2019-08-15 16:58

<fcntl.h>, per http://man7.org/linux/man-pages/man2/fcntl.2.html [^]
(0004527)
shware_systems (reporter)
2019-08-15 19:03

According to the linux kernel header <repo URL>\include\uapi\asm-generic\fcntl.h, the definition is:
struct f_owner_ex {
    int type;
    __kernel_pid_t pid;
};

where __kernel_pid_t may not be assignment compatible with pid_t as defined by a <sys/types.h> that non-kernel sources have access to. There is code that establishes this compatibility when pid_t is expected to be typedef'd as int by <sys/types.h>, but it can be overridden by source files with a conflicting definition of __kernel_pid_t before the #include of that <fcntl.h> header.

This is a conflict between the docs and the source, at the least. Whether a bug report should be filed with the docs people or the source maintainers I couldn't say for sure. It appears the source allows the redefinition for backwards compatibility with processor specific optimizations for versions of the kernel before LINUX deferred to POSIX for some interface definitions. As such I lean to the docs being correct, the source has a regression.
(0004528)
eblake (manager)
2019-08-15 19:32
edited on: 2019-08-15 19:33

re: Note: 0004527
__kernel_pid_t is in the namespace reserved to the implementation, and the standard already forbids users from redefining pid_t (or any other type not starting with __ but ending with _t) from what the standard headers provide. Code that tries to redefine either type before including <fcntl.h> is broken for stomping on reserved namespace, and as such is irrelevant to proper usage of the interface. The libc (whether glibc or musl) is responsible for making sure the userspace struct in <fcntl.h> which defines struct f_owner_ex in terms of userspace pid_t will properly coordinate over to whatever syscall mechanism it uses to communicate with the kernel's internal struct, regardless of whether the kernel has different sizing internally from the public interface. In short, I see no bug here, in either the docs or the public headers.

(0004536)
geoffclare (manager)
2019-08-23 16:15

Proposed changes...

On page 238 line 8002 section <fcntl.h>, add:
The <fcntl.h> header shall define the f_owner_ex structure, which shall include at least the following members:
enum f_pid_type type     Discriminator for pid
pid_t pid                Process ID or process group ID

The <fcntl.h> header shall define the enumerated type enum f_pid_type whose enumerators shall include at least the following:

F_OWNER_PID
The pid member of f_owner_ex holds a process ID.
F_OWNER_PGRP
The pid member of f_owner_ex holds a process group ID.

On page 238 line 8016 section <fcntl.h>, change:
F_GETOWN
Get process or process group ID to receive SIGURG signals.
F_SETOWN
Set process or process group ID to receive SIGURG signals.
to:
F_GETOWN
Get process or process group ID to receive SIGURG signals, via int type.
F_GETOWN_EX
Get process or process group ID to receive SIGURG signals, via pid_t type.
F_SETOWN
Set process or process group ID to receive SIGURG signals, via int type.
F_SETOWN_EX
Set process or process group ID to receive SIGURG signals, via pid_t type.

On page 821 line 27817 section fnctl(), add:
F_GETOWN_EX
If fildes refers to a socket, get the process ID or process group ID specified to receive SIGURG signals when out-of-band data is available, by setting the type and pid members of the f_owner_ex structure pointed to by the third argument, arg. The value of type shall be F_OWNER_PID or F_OWNER_PGRP to indicate that pid contains a process ID or a process group ID, respectively. The value of pid shall be zero if no SIGURG signals are to be sent. If fildes does not refer to a socket, the results are unspecified.
F_SETOWN_EX
If fildes refers to a socket, set the process ID or process group ID specified to receive SIGURG signals when out-of-band data is available, using the value of the third argument, arg, taken as type pointer to struct f_owner_ex. The type and pid members of this structure shall be used as follows:
  • A pid value of zero shall indicate that no SIGURG signals are to be sent.
  • A type value of F_OWNER_PID and a positive pid value shall indicate that SIGURG signals are to be sent to the process ID specified in pid.
  • A type value of F_OWNER_PGRP and a positive pid value shall indicate that SIGURG signals are to be sent to the process group ID specified in pid.
If fildes does not refer to a socket, the results are unspecified.

Move the text from the F_SETOWN description on lines 27803-27816, beginning "Each time a SIGURG signal is sent" and ending "or by other means", to a separate paragraph after the F_SETOWN_EX description, and in it change:
Each time a SIGURG signal is sent
to:
For F_SETOWN and F_SETOWN_EX, each time a SIGURG signal is sent

On page 823 line 27923 section fcntl() (EINVAL shall fail), change:
The cmd argument is invalid, or the cmd argument is F_DUPFD or F_DUPFD_CLOEXEC and arg is negative or greater than or equal to {OPEN_MAX}, or the cmd argument is F_GETLK, F_SETLK, or F_SETLKW and the data pointed to by arg is not valid, or fildes refers to a file that does not support locking.
to:
The cmd argument is invalid; or the cmd argument is F_DUPFD or F_DUPFD_CLOEXEC and arg is negative or is greater than or equal to {OPEN_MAX}; or the cmd argument is F_SETOWN_EX and the type member of the f_owner_ex structure pointed to by arg is invalid, or the pid member is negative and the type member is F_OWNER_PID or F_OWNER_PGRP; or the cmd argument is F_GETLK, F_SETLK, or F_SETLKW and the data pointed to by arg is not valid, or fildes refers to a file that does not support locking.

On page 824 line 27938 section fcntl() (ESRCH), change:
F_SETOWN
to:
F_SETOWN or F_SETOWN_EX

On page 824 line 27944 section fcntl() (EINVAL may fail), change:
The cmd argument is F_SETOWN and the value of the argument is not valid as a process or process group identifier.
to:
The cmd argument is F_SETOWN and the value of arg is positive and is not valid as a process ID or the value of arg is negative and its absolute value is not valid as a process group ID; or the cmd argument is F_SETOWN_EX, the value of the type member of the f_owner_ex structure pointed to by arg is F_OWNER_PID, and the value of the pid member is not valid as a process ID; or the cmd argument is F_SETOWN_EX, the value of the type member of the f_owner_ex structure pointed to by arg is F_OWNER_PGRP, and the value of the pid member is not valid as a process group ID.

On page 824 line 27946 section fcntl() (EPERM), change:
F_SETOWN
to:
F_SETOWN or F_SETOWN_EX

On page 825 line 28011 section fcntl() APPLICATION USAGE, change:
On systems which do not perform permission checks at the time of an fcntl() call with F_SETOWN, ...
to:
On implementations where process IDs can be greater than INT_MAX, F_SETOWN cannot be used with process IDs greater than INT_MAX or process group IDs greater than INT_MAX+1 because the value is passed to fcntl() in an argument of type int. In this situation, F_SETOWN_EX should be used instead.

Similarly, if a process ID greater than INT_MAX or a process group ID greater than INT_MAX+1 has been set to receive SIGURG signals (using F_SETOWN_EX), F_GETOWN cannot be used to obtain the value because fcntl() returns the value as type int and will thus give an [EOVERFLOW] error for such values. F_GETOWN_EX should be used instead.

Note that the convention of negating a process group ID is only used with F_SETOWN and F_GETOWN; the pid member of the f_owner_ex structure used with F_SETOWN_EX and F_GETOWN_EX is not negated when it specifies a process group ID.

On systems which do not perform permission checks at the time of an fcntl() call with F_SETOWN or F_SETOWN_EX, ...

On page 827 line 28077 section fcntl() RATIONALE, add a new paragraph:
The F_SETOWN_EX and F_GETOWN_EX values for cmd and the associated f_owner_ex structure were adopted from the GNU C library. In addition to the values F_OWNER_PID and F_OWNER_PGRP for the type member, this also has F_OWNER_TID to specify that the pid member contains a thread ID. However, this relies on thread IDs being representable in a pid_t and so was not included in POSIX.1-20xx. The aim of adding F_SETOWN_EX and F_GETOWN_EX was to address the inability of F_SETOWN and F_GETOWN to handle process IDs greater than INT_MAX and process group IDs greater than INT_MAX+1, and this need is satisfied without including F_OWNER_TID.
(0004538)
shware_systems (reporter)
2019-08-24 19:56
edited on: 2019-08-24 19:58

The point of the etherpad discussion is it is unsafe to use an enum in the structure definition, and dicey even to use int, due to the potential for the structure to have varying size and therefore break va_arg() type casting for access to structure members. While not as problematic for static compiles, for dynamic link compiles such as in hosted environments or where libc is a shared module it is a potential issue, even when the same compiler Programming Environment is used to compile all modules. As such, the man page, glibc and kernel implementations are all buggy from a portability standpoint. That they work for most applications is accident more than by design and could be considered an exploitable security hole to boot.

So it is immaterial whether an enum or symbolic constants via #define are used to define the index values, the structure definition should be:

The <fcntl.h> header shall define the f_owner_ex structure, which shall begin with the following members, and may include others after these:

int32_t type Discriminator for pid
pid_t pid Process ID or process group ID

with the way the C and POSIX standards are worded now.

The use of int32_t is compatible with 32 bit RISC and CISC alignment requirements, afaik, and the POSIX requirement int type be at least 32-bits. If a 64-bit RISC processor requires 64-bit alignment for fast access it may be better to use int64_t instead. While the pid_t type has similar potential varying width issues, with the above at least references to it will have the same base address.

No one should care that this adds a dependency on <stdint.h> to <fcntl.h>; this is the sort of circumstance that header was created for, and c11 to add the _Align* keywords and <stdalign.h>.

Additional nit, in last paragraph:
     However, this relies on thread IDs being representable in a pid_t and so was not included in POSIX.1-20xx.

should be, I think:
     However, this relies on thread IDs, as represented by the thread_t type, being assignment compatible with pid_t (and have equal or smaller range of allowed values than pid_t) and so was not included in POSIX.1-20xx.

to accentuate <sys/types.h> does not require such compatibility between thread_t and pid_t.

(0004540)
geoffclare (manager)
2019-08-27 15:31

Re: Note: 0004538 I agree that there is a problem with glibc using enum in the struct f_owner_ex definition. Different compilers can make the enum different widths, which means the structure is only binary compatible with the glibc library if the application code is compiled with a compiler that makes the enum the same width as did the compiler that was used to compile glibc.

I think we (probably Eric) should contact the glibc maintainers to point this out and ask if they will agree to change the "type" structure member to int, as shown in the man page.

(I don't see any problem with using int in a structure, and we have many such uses already; if an implementation supports multiple programming environments where int has different widths, then it needs multiple copies of the C library, one for each programming environment.)
(0004541)
shware_systems (reporter)
2019-08-27 16:16
edited on: 2019-08-27 16:17

The problem with int isn't in its width, as that's set by Environment chosen, it's that different compilers may have varying intra-structure alignment usages by default, which the C standard allows. Some may align on bytes, some to 8 bytes. This can break IPC expectations of field offsets in a structure; which a client to hosting environment counts as, being separate compiles. While the int_leastNN types were specified to accommodate this, there are still circumstances where <stdalign.h>, et al, are needed.

(0004542)
eblake (manager)
2019-08-27 16:26

The standard has historically NOT mandated a particular struct layout; it is intentional that implementations are allowed to provide additional fields and/or padding (as long as the presence of those additional fields do not change the behavior of a strictly-conforming application that only uses the standard-mandated fields). For example, 'struct stat' does NOT bother to use uint16_t or int32_t or any other specifically-sized types; its use of 'int' is sufficient for portability (that is, the standard does NOT let you assume a particular layout of struct stat, but portable code does not care about the layout in the first place).

I think that the standard mandating 'int type;' as one of the members of the f_owner_ex structure is sufficient; it is then up to the libc implementation to ensure that the struct that the user space application populates based on what <fcntl.h> declares can then be translated into the appropriate semantics when making a syscall into the kernel (in fact, an implementation that puts the pid_t pid field prior to the int type field would be just as compliant). Thus, whether the glibc implementation uses 'int type;' or 'enum XYZ type;' with a required compilation environment that treats enum XYZ indistinguishable from int, shouldn't really matter to the standard (it becomes a quality-of-implementation issue for glibc if they decide to use a more specific enum type instead of 'int', but as long as a compliant application cannot detect the difference, it shouldn't matter).
(0004543)
geoffclare (manager)
2019-08-28 09:07

Re: Note: 0004542 It's not just the userland-to-kernel compatibility that matters. If the standard says the "type" member is an int, an application should be able to do:
struct f_owner_ex s;

int *foo = &s.type;
but the compiler will complain if the header defines f_owner_ex with an enum instead of an int.
(0004555)
eblake (manager)
2019-09-09 15:19

Per https://sourceware.org/ml/libc-alpha/2019-09/msg00037.html [^] the glibc developers are more likely to switch the user-space <fcntl.h> to use 'int type' (which in turn matches the Linux kernel header type), which means we would need to tweak Note: 0004536 to drop the creation of enum f_pid_type and instead focus on either enum constants or macros for the definitions of F_OWNER_PID and F_OWNERPGRP. Since POSIX would not mandate a layout (and does not require whether 'type' or 'pid' comes first in f_owner_ex), nor prohibit extensions providing other members in the struct, the sizing of any padding in the struct is also not a concern.
(0004556)
geoffclare (manager)
2019-09-10 09:13

New proposed changes that use "int type" in struct f_owner_ex ...

On page 238 line 8002 section <fcntl.h>, add:
The <fcntl.h> header shall define the f_owner_ex structure, which shall include at least the following members:
int type       Discriminator for pid
pid_t pid      Process ID or process group ID

On page 238 line 8016 section <fcntl.h>, change:
F_GETOWN
Get process or process group ID to receive SIGURG signals.
F_SETOWN
Set process or process group ID to receive SIGURG signals.
to:
F_GETOWN
Get process or process group ID to receive SIGURG signals, via int type.
F_GETOWN_EX
Get process or process group ID to receive SIGURG signals, via pid_t type.
F_SETOWN
Set process or process group ID to receive SIGURG signals, via int type.
F_SETOWN_EX
Set process or process group ID to receive SIGURG signals, via pid_t type.

On page 238 line 8026 section <fcntl.h>, add:
The <fcntl.h> header shall also define the following symbolic constants for the type member of the f_owner_ex structure. The values shall be unique.

F_OWNER_PID
The pid member of f_owner_ex holds a process ID.
F_OWNER_PGRP
The pid member of f_owner_ex holds a process group ID.

On page 821 line 27817 section fnctl(), add:
F_GETOWN_EX
If fildes refers to a socket, get the process ID or process group ID specified to receive SIGURG signals when out-of-band data is available, by setting the type and pid members of the f_owner_ex structure pointed to by the third argument, arg. The value of type shall be F_OWNER_PID or F_OWNER_PGRP to indicate that pid contains a process ID or a process group ID, respectively. The value of pid shall be zero if no SIGURG signals are to be sent. If fildes does not refer to a socket, the results are unspecified.
F_SETOWN_EX
If fildes refers to a socket, set the process ID or process group ID specified to receive SIGURG signals when out-of-band data is available, using the value of the third argument, arg, taken as type pointer to struct f_owner_ex. The type and pid members of this structure shall be used as follows:
  • A pid value of zero shall indicate that no SIGURG signals are to be sent.
  • A type value of F_OWNER_PID and a positive pid value shall indicate that SIGURG signals are to be sent to the process ID specified in pid.
  • A type value of F_OWNER_PGRP and a positive pid value shall indicate that SIGURG signals are to be sent to the process group ID specified in pid.
If fildes does not refer to a socket, the results are unspecified.

Move the text from the F_SETOWN description on lines 27803-27816, beginning "Each time a SIGURG signal is sent" and ending "or by other means", to a separate paragraph after the F_SETOWN_EX description, and in it change:
Each time a SIGURG signal is sent
to:
For F_SETOWN and F_SETOWN_EX, each time a SIGURG signal is sent

On page 823 line 27923 section fcntl() (EINVAL shall fail), change:
The cmd argument is invalid, or the cmd argument is F_DUPFD or F_DUPFD_CLOEXEC and arg is negative or greater than or equal to {OPEN_MAX}, or the cmd argument is F_GETLK, F_SETLK, or F_SETLKW and the data pointed to by arg is not valid, or fildes refers to a file that does not support locking.
to:
The cmd argument is invalid; or the cmd argument is F_DUPFD or F_DUPFD_CLOEXEC and arg is negative or is greater than or equal to {OPEN_MAX}; or the cmd argument is F_SETOWN_EX and the type member of the f_owner_ex structure pointed to by arg is invalid, or the pid member is negative and the type member is F_OWNER_PID or F_OWNER_PGRP; or the cmd argument is F_GETLK, F_SETLK, or F_SETLKW and the data pointed to by arg is not valid, or fildes refers to a file that does not support locking.

On page 824 line 27938 section fcntl() (ESRCH), change:
F_SETOWN
to:
F_SETOWN or F_SETOWN_EX

On page 824 line 27944 section fcntl() (EINVAL may fail), change:
The cmd argument is F_SETOWN and the value of the argument is not valid as a process or process group identifier.
to:
The cmd argument is F_SETOWN and the value of arg is positive and is not valid as a process ID or the value of arg is negative and its absolute value is not valid as a process group ID; or the cmd argument is F_SETOWN_EX, the value of the type member of the f_owner_ex structure pointed to by arg is F_OWNER_PID, and the value of the pid member is not valid as a process ID; or the cmd argument is F_SETOWN_EX, the value of the type member of the f_owner_ex structure pointed to by arg is F_OWNER_PGRP, and the value of the pid member is not valid as a process group ID.

On page 824 line 27946 section fcntl() (EPERM), change:
F_SETOWN
to:
F_SETOWN or F_SETOWN_EX

On page 825 line 28011 section fcntl() APPLICATION USAGE, change:
On systems which do not perform permission checks at the time of an fcntl() call with F_SETOWN, ...
to:
On implementations where process IDs can be greater than INT_MAX, F_SETOWN cannot be used with process IDs greater than INT_MAX or process group IDs greater than INT_MAX+1 because the value is passed to fcntl() in an argument of type int. In this situation, F_SETOWN_EX should be used instead.

Similarly, if a process ID greater than INT_MAX or a process group ID greater than INT_MAX+1 has been set to receive SIGURG signals (using F_SETOWN_EX), F_GETOWN cannot be used to obtain the value because fcntl() returns the value as type int and will thus give an [EOVERFLOW] error for such values. F_GETOWN_EX should be used instead.

Note that the convention of negating a process group ID is only used with F_SETOWN and F_GETOWN; the pid member of the f_owner_ex structure used with F_SETOWN_EX and F_GETOWN_EX is not negated when it specifies a process group ID.

On systems which do not perform permission checks at the time of an fcntl() call with F_SETOWN or F_SETOWN_EX, ...

On page 827 line 28077 section fcntl() RATIONALE, add a new paragraph:
The F_SETOWN_EX and F_GETOWN_EX values for cmd and the associated f_owner_ex structure were adopted from the GNU C library. In addition to the values F_OWNER_PID and F_OWNER_PGRP for the type member, this also has F_OWNER_TID to specify that the pid member contains a thread ID. However, this relies on thread IDs being representable in a pid_t and so was not included in POSIX.1-20xx. The aim of adding F_SETOWN_EX and F_GETOWN_EX was to address the inability of F_SETOWN and F_GETOWN to handle process IDs greater than INT_MAX and process group IDs greater than INT_MAX+1, and this need is satisfied without including F_OWNER_TID.

- Issue History
Date Modified Username Field Change
2019-07-28 10:42 dannyniu New Issue
2019-07-28 10:42 dannyniu Name => DannyNiu/NJF
2019-07-28 10:42 dannyniu Organization => Individual
2019-07-28 10:42 dannyniu Section => <sys/types.h> header
2019-07-28 10:42 dannyniu Page Number => 402-405
2019-07-28 10:42 dannyniu Line Number => 13652-13746
2019-07-28 13:49 jilles Note Added: 0004496
2019-07-29 00:52 shware_systems Note Added: 0004497
2019-07-29 09:08 geoffclare Note Added: 0004498
2019-08-15 16:37 eblake Note Added: 0004524
2019-08-15 16:52 shware_systems Note Added: 0004525
2019-08-15 16:58 eblake Note Added: 0004526
2019-08-15 19:03 shware_systems Note Added: 0004527
2019-08-15 19:32 eblake Note Added: 0004528
2019-08-15 19:33 eblake Note Edited: 0004528
2019-08-23 16:15 geoffclare Note Added: 0004536
2019-08-24 19:56 shware_systems Note Added: 0004538
2019-08-24 19:58 shware_systems Note Edited: 0004538
2019-08-27 15:31 geoffclare Note Added: 0004540
2019-08-27 16:16 shware_systems Note Added: 0004541
2019-08-27 16:17 shware_systems Note Edited: 0004541
2019-08-27 16:26 eblake Note Added: 0004542
2019-08-28 09:07 geoffclare Note Added: 0004543
2019-09-09 15:19 eblake Note Added: 0004555
2019-09-10 09:13 geoffclare Note Added: 0004556
2022-07-11 16:25 geoffclare Interp Status => ---
2022-07-11 16:25 geoffclare Final Accepted Text => Note: 0004556
2022-07-11 16:25 geoffclare Status New => Resolved
2022-07-11 16:25 geoffclare Resolution Open => Accepted As Marked
2022-07-11 16:26 geoffclare Tag Attached: issue8
2022-08-05 09:42 geoffclare Status Resolved => Applied
2023-04-17 15:28 geoffclare Relationship added related to 0001670
2024-06-11 09:08 agadmin Status Applied => Closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker