dtable::set_file_pointers_for_exec is called from
child_info_spawn::worker to move the file position of O_APPEND
files to EOF if the child is a native child.
However, this only works correctly for the first O_APPEND
file descriptor:
- set_file_pointers_for_exec calls SetFilePointer. The higher
4 bytes of the desired file offset are given to SetFilePointer
as pointer to a DWORD value. On return, SetFilePointer returns
the higher 4 bytes of the new file position in this DWORD.
- So for the second and subsequent descriptors the higher 4 byte
of the file position depend on what the actual file position
of the previous file has been set to:
- If the file is > 2 Gigs, the high offset will not be 0 anymore.
- If the desciptor points to a non-seekable file (i.e., a pipe
or socket), SetFilePosition returns an error and sets the high
position to -1.
Fix this by calling SetFilePointerEx instead, which does not
modify the incoming position value.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Using the Windows PID as Cygwin PID has a few drawbacks:
- the PIDs on Windows get reused quickly. Some POSIX applications choke
on that, so we need extra code to avoid too quick PID reuse.
- The code to avoid PID reuse keeps parent process handles and
(depending on a build option) child processes open unnecessarily.
- After an execve, the process has a split personality: Its Windows PID
is a new PID, while its Cygwin PID is the PID of the execve caller
process. This requires to keep two procinfo shared sections open, the
second just to redirect process info requests to the first, correct
one.
This patch changes the way Cygwin PIDs are generated:
- Cygwin PIDs are generated independently of the Windows PID, in a way
expected by POSIX processes. The PIDs are created incrementally in
the range between 2 and 65535, round-robin.
- On startup of the first Cygwin process, choose a semi-random start PID
for the first process in the lower PID range to make the PIDs slightly
unpredictable. This may not be necessary but it seems kind of inviting
to know that the first Cygwin process always starts with PID 2.
- Every process not only creates the shared procinfo section, but also a
symlink in the NT namespace, symlinking the Windows PID to the Cygwin
PID. This drops the need for the extra procinfo section after execve.
- Don't keep other process handles around unnecessarily.
- Simplify the code creating/opening the shared procinfo section and
make a clear distinction between interfaces getting a Cygwin PID and
interfaces getting a Windows PID.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
POSIX requires that raise(3) is equivalent to
pthread_kill(pthread_self(), sig);
in multi-threaded applications. Our raise just called kill(sig).
Fix that.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- This simple and official method replaces cyglsa and "create token"
methods. No network share access, same as before.
- lsaauth and create_token are disabled now. If problems crop up,
they can be easily reactivated. If no problems crop up, they
can be removed in a while, together with the lsaauth subdir.
- Bump Cygwin version to 3.0.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
So far seteuid could change uid to any existing account, given
sufficient permissions of the caller. This is kind of bad since
it disallows admins to refuse login to disabled or locked out
accounts.
Add check for the account's UF_ACCOUNTDISABLE or UF_LOCKOUT flags
and don't let the user in, if one of the flags is set.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
If gethostname() fails we call GetComputerNameEx with
ComputerNameDnsFullyQualified. This is wrong, gethostname should return
the hostname only, not the FQDN. Fix this by calling GetComputerNameEx
with ComputerNameDnsHostname.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
When reusing a cygthread, the stub method fails to set the thread name
to the new name. The name is only set when actually creating the
thread. Fix that by moving the SetThreadName call right in front of the
thread function call.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
First cut of a timerfd implementation.
Still TODO:
- fork/exec semantics
- timerfd_settime TFD_TIMER_CANCEL_ON_SET flag
- ioctl(TFD_IOC_SET_TICKS)
- bug fixes
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
First cut of a signalfd implementation.
Still TODO: Non-polling select.
This should mostly work as on Linux except for missing support
for some members of struct signalfd_siginfo, namely ssi_fd,
ssi_band (both SIGIO/SIGPOLL, not fully implemented) and ssi_trapno
(HW exception, required HW support).
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
There's a long-standing bug in select. If we have poll-only
descriptors in the fd set, select overwrites the incoming
fd sets with the polling result. If none of the fds is ready,
select has to loop again. But now the fd sets are set to all
zero and select hangs.
Fix this by utilizing the local fd sets r, w, e as storage for
the incoming fd sets and use them to initialize select_stuff.
If we have to loop, overwritung the incoming fd sets doesn't matter.
While at it, rename r, w, e to readfds_in, writefds_in, exceptfds_in.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
fhandler_socket_wsock::set_socket_handle calls set_flags after
setting the O_NONBLOCK/O_CLOEXEC flags, thus overwriting them.
It also turns out that fhandler_socket_wsock::init_events is called
too late. The inheritence flags are changed before creating the
socket event handling objects. Thus, inheritence flags for
those objects are wrong with SOCK_CLOEXEC.
Fix this by reordering the calls and setting the file flags through
fhandler_base::set_flags.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Regression introduced with 2.11.0:
The failure paths in socket, socketpair and accept4 functions and
methods accidentally release *unused* cygheap_fdmanip objects. The
subsequently called dtable::release method was designed to be called for
*used* cygheap_fdmanip objects only. Using them on unused objects leads
to NULL pointer member dereferencing.
Worse, the inet/local accept4 methods only release the cygheap_fdmanip
object but neglect to delete the just created fhandler_socket_* object.
Fix this by removing the erroneous release calls in the aforementioned
failure paths and delete the fhandler_socket_* object in accept4 instead.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The fhandler_base_overlapped::copyto clears atomic_write_buf on the
clone, but none of the derived classes were doing this. This allowed
the destructor to double-free the buffer and corrupt cygheap.
Clear atomic_write_buf in copyto of all derived classes.
Commit 35998fc2fa fixed the buffer underun
in win32 path normalization, but introduced a new bug: A wrong
assumption led to the inability to backtrack the path outside of the
current working directory in case of relative paths.
This patch fixes this problem, together with a minor problem if the CWD
is on a network share: The result erroneously started with tripple
backslash if the src path starts with a single backslash.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Starting with Windows 10, LookupAccountSid/Name return valid
info for the login session with new SID_NAME_USE value
SidTypeLogonSession. To return the same info as on pre-Windows 10,
we have to handle this type.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This patch follows glibc. Original commit message:
Author: Florian Weimer <fweimer@redhat.com>
Date: Thu, 14 Apr 2016 06:54:57 +0000
Remove union wait [BZ #19613]
The overloading approach in the W* macros was incompatible with
integer expressions of a type different from int. Applications
using union wait and these macros will have to migrate to the
POSIX-specified int status type.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* create new function __get_cpus_per_group to evaluate # of CPU groups
* Call from format_proc_cpuinfo and sched_getcpu
* Bump API minor version
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Updates to misc files to integrate AIO into the Cygwin source tree.
Much of it has to be done when adding any new syscalls. There are
some updates to limits.h for AIO-specific limits. And some doc mods.
Certain tape drives (known example: QUANTUM_ULTRIUM-HH6) return
the non-standard ERROR_NOT_READY rather than ERROR_NO_MEDIA_IN_DRIVE
if no media is present. ERROR_NOT_READY is not documented as valid
return code from GetTapeStatus. Without handling this error code
Cygwin's tape code can't report an offline state to user space.
Fix this by converting ERROR_NOT_READY to ERROR_NO_MEDIA_IN_DRIVE
where appropriate.
Add a debug_printf to mtinfo_drive::get_status to allow requesting
user info without having to rebuild the DLL.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- Move pthread_join to thread.cc to have all `join' calls in
the same file (pthread_timedjoin_np needs pthread_convert_abstime
which is static inline in thread.cc)
- Bump API version
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
When reading/writing block devices, Cygwin emulates Linux, providing
a byte-exact file position, albeit the underlying device drivers don't.
Unfortunately this only worked correctly for reading. The raw_write
method failed to revalidate the buffer after the read-modify-write
cycle in case len is not a multiple of the sector length. This in
turn resulted in lseek reporting a wrong file pointer.
Also, fix a condition for invalidating the buffer after writing from
a remaining read buffer.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The original dll_init code was living under the wrong assumption that
dll_dllcrt0_1 and in turn dll_list::alloc will be called for each
LoadLibrary call. The same wrong assumption was made for
cygwin_detach_dll/dll_list::detach called via FreeLibrary.
In reality, dll_dllcrt0_1 gets only called once at first LoadLibrary
and cygwin_detach_dll once at last FreeLibrary.
In effect, reference counting for DLLs was completely broken after fork:
parent:
l1 = dlopen ("lib1"); // LoadLibrary, LoadCount = 1
l2 = dlopen ("lib1"); // LoadLibrary, LoadCount = 2
fork (); // LoadLibrary in the child, LoadCount = 1!
child:
dlclose (l1); // FreeLibrary actually frees the lib
x = dlsym (l2); // SEGV
* Move reference counting to dlopen/dlclose since only those functions
have to keep track of loading/unloading DLLs in the application context.
* Remove broken accounting code from dll_list::alloc and dll_list::detach.
* Fix error handling in dlclose.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Note that this always returns with dli_sname and dli_saddr set to NULL,
indicating no symbol matching addr could be found.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
This patch alters the behaviour of dll_list::topsort to preserve the
order of dlopen'd units.
The load order of unrelated DLLs is reversed every time fork is called,
since dll_list::topsort finds the tail of the list and then unwinds to
reinsert items. My change takes advantage of what should be undefined
behaviour in dll_list::populate_deps (ndeps non-zero and ndeps and deps
not initialised) to allow the deps field to be initialised prior to the
call and appended to, rather than overwritten.
All DLLs which have been dlopen'd have their deps list initialised with
the list of all previously dlopen'd units. These extra dependencies mean
that the unwind preserves the order of dlopen'd units.
The motivation for this is the FlexDLL linker used in OCaml. The FlexDLL
linker allows a dlopen'd unit to refer to symbols in previously dlopen'd
units and it resolves these symbols in DllMain before anything else has
initialised (including the Cygwin DLL). This means that dependencies may
exist between dlopen'd units (which the OCaml runtime system
understands) but which Windows is unaware of. During fork, the
process-level table which FlexDLL uses to get the symbol table of each
DLL is copied over but because the load order of dlopen'd DLLs is
reversed, it is possible for FlexDLL to attempt to access memory in the
DLL before it has been loaded and hence it fails with an access
violation. Because the list is reversed on each call to fork, it means
that a subsequent call to fork puts the DLLs back into the correct
order, hence "even" invocations of fork work!
An interesting side-effect is that this only occurs if the DLLs load at
their preferred base address - if they have to be rebased, then FlexDLL
works because at the time that the dependent unit is loaded out of
order, there is still in memory the "dummy" DONT_RESOLVE_DLL_REFERENCES
version of the dependency which, as it happens, will contain the correct
symbol table in the data section. For my tests, this initially appeared
to be an x86-only problem, but that was only because the two DLLs on x64
should have been rebased.
Signed-off-by: David Allsopp <david.allsopp@metastack.com>
Update the getconf utility to support the new flag as well as
_PC_POSIX_PERMISSIONS and _PC_POSIX_SECURITY. These were previously
unsupported, probably as an oversight.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Long-standing problem in one of the corner cases of rename(2):
If we rename a directory a check is performed to see if newpath is
identical to oldpath or a subdir of oldpath. This check is
(accidentally? no hints anywhere in ChangeLogs or code) performed
case-insensitive for as long as we use Unicode paths and NT functions.
This leads to the problems described in
https://cygwin.com/ml/cygwin/2016-09/msg00264.html
Change this to be conditional case-sensitive as all other checks but
let's take this with a grain of salt. There may be corner-cases in
this corner-case which require to chek parts of the path always
case-insensitive. Off the top of my head I can't construct such a
case but that's no proof they don't exist :}
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
On Windows 8.1 and later, the NetUserChangePassword call apparently
doesn't accept the usual "\\server" string anymore, but requires to
use the "domain" instead, otherwise it emits en error code 1265,
ERROR_DOWNGRADE_DETECTED. Since this is accepted by pre-8.1 as well,
use the domain indiscriminately when calling NetUserChangePassword
from passwd(1).
While at it, do some minor cleanup in passwd.c.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This patch adds pthread_getname_np and pthread_setname_np.
These were added to glibc in 2.12[1] and are also present in some form on
NetBSD and several UNIXes.
The code is based on NetBSD's implementation with changes to better match
Linux behaviour.
Implementation quirks:
* pthread_setname_np with a NULL pointer segfaults (as linux)
* pthread_setname_np returns ERANGE for names longer than 16 characters (as
linux)
* pthread_getname_np with a NULL pointer returns EFAULT (as linux)
* pthread_getname_np with a buffer length of less than 16 returns ERANGE (as
linux)
* pthread_getname_np truncates the thread name to fit the buffer length.
This guarantees success even when the default thread name is longer than 16
characters, but means there is no way to discover the actual length of the
thread name. (Linux always truncates the thread name to 16 characters)
* Changing program_invocation_short_name changes the default thread name (on
linux, it has no effect on the default thread name)
I'll leave it up to you to decide if any of these matter.
This is implemented via class pthread_attr to make it easier to add
pthread_attr_[gs]etname_np (present in NetBSD and some UNIXes) should it
ever be added to Linux (or we decide we want it anyway).
[1] https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS
POSIX requires that SSIZE_MAX have the same type as ssize_t, but
on 32-bit, we were defining it as a long even though ssize_t
resolves to an int. It also requires that SSIZE_MAX be usable
via preprocessor #if, so we can't cheat and use a cast.
If this were newlib, I'd have had to hack _intsup.h to probe the
qualities of size_t (via gcc's __SIZE_TYPE__), similar to how we
already probe the qualities of int8_t and friends, then cross our
fingers that ssize_t happens to have the same rank (most systems
do, but POSIX permits a system where they differ such as size_t
being long while ssize_t is int). Unfortunately gcc gives us
neither __SSIZE_TYPE__ nor __SSIZE_MAX__. On the other hand, our
limits.h is specific to cygwin, so we can just shortcut to the
correct results rather than being generic to all possible ABI.
Signed-off-by: Eric Blake <eblake@redhat.com>
Michael Haubenwallner
Corinna Vinschen
Jozef Lawrynowicz
David McFarland
Ken Brown
Mark Geisert
Yaakov Selkowitz
Jon Turney
David Allsopp
Eric Blake