uc_sigmask set in a sigaction signal handler not honored
Hi. Correct me if I'm wrong but POSIX appears to define
https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html
as, among other things, containing the field:
sigset_tuc_sigmask the set of signals that are blocked when this
context is active
and it also specifies that the third argument to a .sa_sigaction
signal handler is a ucontext_t* cast to void*.
So it should follow that doing
void act(int Sig, siginfo_t *Info, void *Uctx)
{
ucontext_t *uctx = Uctx;
sigfillset(&uctx->uc_sigmask);
}
from a signal handler should alter the signal mask of the thread the
signal ran on.
This is how Linux and MacOS behave, but not CygWin, as the following
program shows:
#include
#include
#include
#include
#include
void prmask(void)
{
sigset_t mask; pthread_sigmask(SIG_SETMASK,0,&mask);
for(int i=1; i<=64; i++){ printf("%d", sigismember(&mask,i)); }
puts("");
}
void act(int Sig, siginfo_t *Info, void *Uctx)
{
ucontext_t *uctx = Uctx;
sigfillset(&uctx->uc_sigmask);
}
int main()
{
struct sigaction sa;
sa.sa_sigaction = act;
sa.sa_flags = SA_SIGINFO;
sigfillset(&sa.sa_mask);
prmask();
sigaction(SIGINT,&sa,0);
sigaction(SIGALRM,&sa,0);
if(1)
setitimer(ITIMER_REAL,&(struct
itimerval){.it_value={.tv_usec=1}},0);
pause();
prmask();
}
I think this is a bug, so I'm reporting it. Do you think it can be fixed
in the near future?
Best regards,
Petr Skocik
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: uc_sigmask set in a sigaction signal handler not honored
On Apr 3 11:27, Petr Skočík wrote:
> Hi. Correct me if I'm wrong but POSIX appears to define
>
> https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html
>
> as, among other things, containing the field:
>
> sigset_tuc_sigmask the set of signals that are blocked when this
> context is active
>
> and it also specifies that the third argument to a .sa_sigaction
> signal handler is a ucontext_t* cast to void*.
>
> So it should follow that doing
>
> void act(int Sig, siginfo_t *Info, void *Uctx)
> {
> ucontext_t *uctx = Uctx;
> sigfillset(&uctx->uc_sigmask);
> }
>
> from a signal handler should alter the signal mask of the thread the
> signal ran on.
>
> This is how Linux and MacOS behave, but not CygWin, as the following
> program shows:
What you're asking for is really complicated.
The context given to act is the context at the time the signal function
is called. In Cygwin (lower case w) this is a copy of the context.
sigfillset() has not the faintest clue where this context comes from, it
just sets the signal mask value without taking any further action.
There are no provisions to control if the called function changes the
context, other than via setcontext / swapcontext, and I don't see that
POSIX requires anything else. Both functions change the current
thread's sigmask according to the value of uc_sigmask.
HTH,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Re: cygwin port of glib
On 05.03.2019 17:23, LRN wrote: > On 05.03.2019 17:07, E. Madison Bray wrote: >> >> If they're clean, worthwhile patches then I absolutely think you >> should get them integrated upstream if at all possible--that's almost >> always preferable. > > Okay, i'll see what i can do. > Made some progress, but i would benefit from some input on a few things. 1) This[0] cygwinports commit and a related gnulib[1] commit. Which version of cygwin (CYGWIN_VERSION_API_MINOR) corresponds to 1.7 (is the 1.7 number even correct?). As a less-intrusive fix, i can switch #ifdef __CYGWIN__ to #if defined(__CYGWIN) && (!defined (CYGWIN_VERSION_API_MINOR) || CYGWIN_VERSION_API_MINOR < somevalue) 2) This[2] cygwinports commit. I don't quite get what the author means. Does he mean that returning a path that looks like "//etc" from parsing a URI "file:etc" is correct? Or the opposite, that it should return "/etc" ? The commit seems to be saying one thing, while the code does something else. [0]: https://github.com/cygwinports/glib2.0/commit/b61abed9554ab813ed358ea5bad648987573772e#diff-2d64c930085856723abe9a40105389abR256 [1]: https://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/localcharset.c?id=9f5ab735f030faf651961d55ce3b849dd56dcff3 [2]: https://github.com/cygwinports/glib2.0/commit/40ca93c8ae81e7a05ec098246b43ce74e157ebd6#diff-c86c0d1edc7cdc043b8b01ee6e526817 signature.asc Description: OpenPGP digital signature
Re: uc_sigmask set in a sigaction signal handler not honored
On Apr 3 14:15, Corinna Vinschen wrote:
> On Apr 3 11:27, Petr Skočík wrote:
> > Hi. Correct me if I'm wrong but POSIX appears to define
> >
> > https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html
> >
> > as, among other things, containing the field:
> >
> > sigset_tuc_sigmask the set of signals that are blocked when this
> > context is active
> >
> > and it also specifies that the third argument to a .sa_sigaction
> > signal handler is a ucontext_t* cast to void*.
> >
> > So it should follow that doing
> >
> > void act(int Sig, siginfo_t *Info, void *Uctx)
> > {
> > ucontext_t *uctx = Uctx;
> > sigfillset(&uctx->uc_sigmask);
> > }
> >
> > from a signal handler should alter the signal mask of the thread the
> > signal ran on.
> >
> > This is how Linux and MacOS behave, but not CygWin, as the following
> > program shows:
>
> What you're asking for is really complicated.
>
> The context given to act is the context at the time the signal function
> is called. In Cygwin (lower case w) this is a copy of the context.
>
> sigfillset() has not the faintest clue where this context comes from, it
> just sets the signal mask value without taking any further action.
>
> There are no provisions to control if the called function changes the
> context, other than via setcontext / swapcontext, and I don't see that
> POSIX requires anything else. Both functions change the current
> thread's sigmask according to the value of uc_sigmask.
Or maybe I'm just dumb. Would it suffice if the thread's signal mask is
changed to uc_sigmask when the signal function returns?
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Re: uc_sigmask set in a sigaction signal handler not honored
> On Apr 3 14:15, Corinna Vinschen wrote:
> > On Apr 3 11:27, Petr Skočík wrote:
> > > Hi. Correct me if I'm wrong but POSIX appears to define
> > >
> > > https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html
> > >
> > > as, among other things, containing the field:
> > >
> > > sigset_tuc_sigmask the set of signals that are blocked when this
> > > context is active
> > >
> > > and it also specifies that the third argument to a .sa_sigaction
> > > signal handler is a ucontext_t* cast to void*.
> > >
> > > So it should follow that doing
> > >
> > > void act(int Sig, siginfo_t *Info, void *Uctx)
> > > {
> > > ucontext_t *uctx = Uctx;
> > > sigfillset(&uctx->uc_sigmask);
> > > }
> > >
> > > from a signal handler should alter the signal mask of the thread the
> > > signal ran on.
> > >
> > > This is how Linux and MacOS behave, but not CygWin, as the following
> > > program shows:
> >
> > What you're asking for is really complicated.
> >
> > The context given to act is the context at the time the signal function
> > is called. In Cygwin (lower case w) this is a copy of the context.
> >
> > sigfillset() has not the faintest clue where this context comes from, it
> > just sets the signal mask value without taking any further action.
> >
> > There are no provisions to control if the called function changes the
> > context, other than via setcontext / swapcontext, and I don't see that
> > POSIX requires anything else. Both functions change the current
> > thread's sigmask according to the value of uc_sigmask.
>
> Or maybe I'm just dumb. Would it suffice if the thread's signal mask is
> changed to uc_sigmask when the signal function returns?
>
>
> Corinna
Thanks for the feedback.
> Would it suffice if the thread's signal mask is
> changed to uc_sigmask when the signal function returns?
That is the idea. It's what Linux and MacOS do.
Petr Skocik
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygpath -u converts quoted UNC paths to local
Greetings, All! This can be considered "working by design", but it really imposes some serious restrictions on interoperability with Cygwin, that I think can be avoided. ... After some further testing, this seems to be affecting IP-based UNC paths only. The essence is this: $ dir "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" 26.10.2018 18:16 431 online.sh $ cygpath -u \\192.168.1.5\wwwroot\ccenter\bin\online.sh //192.168.1.5/wwwroot/ccenter/bin/online.sh $ cygpath -u "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" /192.168.1.5/wwwroot/ccenter/bin/online.sh $ cygpath -u \\HOSTING64.DARKDRAGON.LAN\wwwroot\ccenter\bin\online.sh //HOSTING64.DARKDRAGON.LAN/wwwroot/ccenter/bin/online.sh $ cygpath -u "\\HOSTING64.DARKDRAGON.LAN\wwwroot\ccenter\bin\online.sh" //HOSTING64.DARKDRAGON.LAN/wwwroot/ccenter/bin/online.sh $ -- With best regards, Andrey Repin Wednesday, April 3, 2019 19:11:14 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: uc_sigmask set in a sigaction signal handler not honored
On Apr 3 16:39, Petr Skočík wrote:
> > On Apr 3 14:15, Corinna Vinschen wrote:
> > > On Apr 3 11:27, Petr Skočík wrote:
> > > > Hi. Correct me if I'm wrong but POSIX appears to define
> > > >
> > > > https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h.html
> > > >
> > > > as, among other things, containing the field:
> > > >
> > > > sigset_tuc_sigmask the set of signals that are blocked when this
> > > > context is active
> > > >
> > > > and it also specifies that the third argument to a .sa_sigaction
> > > > signal handler is a ucontext_t* cast to void*.
> > > >
> > > > So it should follow that doing
> > > >
> > > > void act(int Sig, siginfo_t *Info, void *Uctx)
> > > > {
> > > > ucontext_t *uctx = Uctx;
> > > > sigfillset(&uctx->uc_sigmask);
> > > > }
> > > >
> > > > from a signal handler should alter the signal mask of the thread the
> > > > signal ran on.
> > > >
> > > > This is how Linux and MacOS behave, but not CygWin, as the following
> > > > program shows:
> > >
> > > What you're asking for is really complicated.
> > >
> > > The context given to act is the context at the time the signal function
> > > is called. In Cygwin (lower case w) this is a copy of the context.
> > >
> > > sigfillset() has not the faintest clue where this context comes from, it
> > > just sets the signal mask value without taking any further action.
> > >
> > > There are no provisions to control if the called function changes the
> > > context, other than via setcontext / swapcontext, and I don't see that
> > > POSIX requires anything else. Both functions change the current
> > > thread's sigmask according to the value of uc_sigmask.
> >
> > Or maybe I'm just dumb. Would it suffice if the thread's signal mask is
> > changed to uc_sigmask when the signal function returns?
>
> Thanks for the feedback.
>
> > Would it suffice if the thread's signal mask is
> > changed to uc_sigmask when the signal function returns?
>
> That is the idea. It's what Linux and MacOS do.
I pushed a patch which, for now, only sets the thread's sigmask to the
value set by the signal handler in uc_sigmask.
I have code in the loop allowing the signal handler to change the entire
context. The code the signal handler returns to would check if the
handler changed the context and call setcontext if so. However, I'm
reluctant to push it without having some serious, simple testcase.
As for restoring the thread signal mask, I uploaded new developer
snapshots to https://cygwin.com/snapshots/ for testing. Please give
them a try.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Re: cygpath -u converts quoted UNC paths to local
On Apr 3 19:20, Andrey Repin wrote: > Greetings, All! > > This can be considered "working by design", but it really imposes some serious > restrictions on interoperability with Cygwin, that I think can be avoided. > > ... > > After some further testing, this seems to be affecting IP-based UNC paths > only. > > The essence is this: > > $ dir "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" > 26.10.2018 18:16 431 online.sh > > $ cygpath -u \\192.168.1.5\wwwroot\ccenter\bin\online.sh > //192.168.1.5/wwwroot/ccenter/bin/online.sh > > $ cygpath -u "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" > /192.168.1.5/wwwroot/ccenter/bin/online.sh This shows that it's not cygpath. It's the quoting, thus the shell mangles the path. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: cygpath -u converts quoted UNC paths to local
Andrey Repin writes: > This can be considered "working by design", but it really imposes some serious > restrictions on interoperability with Cygwin, that I think can be avoided. But cygpath never sees the quotes, so whatever is done to the path that it gets is actually the work of your shell. In other words, you need to shell-quote the backslashes as appropriate for your shell. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: EXT: Re: cygpath -u converts quoted UNC paths to local
Not completely the shell. From a Windows command prompt: c:\Apps\cygwin64\bin\cygpath.exe -u \\123.456.789.321\wwwroot\ccenter\bin\online.sh //123.456.789.321/wwwroot/ccenter/bin/online.sh c:\Apps\cygwin64\bin\cygpath.exe -u "\\123.456.789.321\wwwroot\ccenter\bin\online.sh" /cygdrive/c/123.456.789.321/wwwroot/ccenter/bin/online.sh c:\Apps\cygwin64\bin\cygpath.exe -u "\\\123.456.789.321\wwwroot\ccenter\bin\online.sh" //123.456.789.321/wwwroot/ccenter/bin/online.sh c:\Apps\cygwin64\bin\cygpath.exe -u "123.456.789.321\wwwroot\ccenter\bin\online.sh" //123.456.789.321/wwwroot/ccenter/bin/online.sh Looks like cygpath is doing something different when the argument is enclosed in quotes (same behavior if single-quote ' is used). > -Original Message- > From: cygwin-ow...@cygwin.com On Behalf > Of Achim Gratz > Sent: Wednesday, April 03, 2019 1:12 PM > To: cygwin@cygwin.com > Subject: EXT: Re: cygpath -u converts quoted UNC paths to local > > Andrey Repin writes: > > This can be considered "working by design", but it really imposes some > > serious restrictions on interoperability with Cygwin, that I think can be > avoided. > > But cygpath never sees the quotes, so whatever is done to the path that it > gets is actually the work of your shell. In other words, you need to shell- > quote the backslashes as appropriate for your shell. > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk > Blofeld]>+ > > DIY Stuff: > http://Synth.Stromeko.net/DIY.html > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygpath -u converts quoted UNC paths to local
On 2019-04-03 12:20 pm, Andrey Repin wrote: Greetings, All! This can be considered "working by design", but it really imposes some serious restrictions on interoperability with Cygwin, that I think can be avoided. ... After some further testing, this seems to be affecting IP-based UNC paths only. The essence is this: $ dir "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" 26.10.2018 18:16 431 online.sh $ cygpath -u \\192.168.1.5\wwwroot\ccenter\bin\online.sh //192.168.1.5/wwwroot/ccenter/bin/online.sh $ cygpath -u "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" /192.168.1.5/wwwroot/ccenter/bin/online.sh $ cygpath -u \\HOSTING64.DARKDRAGON.LAN\wwwroot\ccenter\bin\online.sh //HOSTING64.DARKDRAGON.LAN/wwwroot/ccenter/bin/online.sh $ cygpath -u "\\HOSTING64.DARKDRAGON.LAN\wwwroot\ccenter\bin\online.sh" //HOSTING64.DARKDRAGON.LAN/wwwroot/ccenter/bin/online.sh $ Using echo is a good way of checking just what the shell is handing to your program. But I totally agree that this is a major interoperability annoyance. I'm using Bash 4.4.12(3): $ echo \\192.168.1.5\wwwroot\ccenter\bin\online.sh \192.168.1.5wwwrootccenterbinonline.sh $ echo "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" \192.168.1.5\wwwroot\ccenter\bin\online.sh $ echo '\\192.168.1.5\wwwroot\ccenter\bin\online.sh' \\192.168.1.5\wwwroot\ccenter\bin\online.sh $ echo \\foo\wwwroot\ccenter\bin\online.sh \foowwwrootccenterbinonline.sh $ echo "\\foo\wwwroot\ccenter\bin\online.sh" \foo\wwwroot\ccenter\bin\online.sh $ echo '\\foo\wwwroot\ccenter\bin\online.sh' \\foo\wwwroot\ccenter\bin\online.sh read -r is an alternate way of getting text into a command line that might otherwise turn into quoting hell. $ read -r; cygpath -u $REPLY \\192.168.1.5\wwwroot\ccenter\bin\online.sh //192.168.1.5/wwwroot/ccenter/bin/online.sh -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
sshd_config request: hostname token
It seems it would be useful to have a hostname token for use in the sshd_config file. Example usage (supposing %H expands to the hostname): AllowGroups "%H+SSH Users" This would permit access on the local computer (no matter its name) if the account is a member of the SSH Users group (if it's a domain member). This would allow users to change the name of the computer without needing to edit the sshd_config file (if the computer is a domain member). If the computer is removed from the domain, you still have to remove the %H+ prefix. [Aside: This is one of the reasons I find Cygwin's account matching algorithm to be "backwards," for lack of a better term. IMO local account names should resolve before domain account names if the computer is a domain member. If local accounts matched first, all you would need is AllowGroups "SSH Users" and be done with it. But I realize this is a big change.] Are there risks with adding a hostname token that I'm not seeing? Thanks Bill -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
