Logging-in using ssh elevates the user privilege.

Logging-in using ssh elevates the user privilege.

[Takashi Yano]

Hello,

I would like to report a problem of recent cygwin.

If a user logs in via ssh, the user aqcuires the elevated
privilege if the user belongs to Administrators group.

The following log is the example of the behaviour.

[yano@Express5800-S70 ~]$ touch /cygdrive/c/windows/testfile
touch: cannot touch '/cygdrive/c/windows/testfile': Permission denied
[yano@Express5800-S70 ~]$ ssh localhost
yano@localhost's password:
Last login: Thu Mar  7 00:06:21 2019 from ::1
CYGWIN_NT-10.0-WOW Express5800-S70 3.0.2(0.338/5/3) 2019-03-05 19:01 i686 Cygwin
[yano@Express5800-S70 ~]$ touch /cygdrive/c/windows/testfile
[yano@Express5800-S70 ~]$ rm /cygdrive/c/windows/testfile
[yano@Express5800-S70 ~]$ exit
logout
Connection to localhost closed.
[yano@Express5800-S70 ~]$

Because of this behaviour, the process started in a ssh
session cannot be killed from a normal mintty session.

This also causes gnu screen to freeze.

To reproduce this:
(1) Start screen in mintty window.
(2) Detatch from the screen (Ctrl-A d).
(3) Login via ssh.
(4) Attach screen by 'screen -r' in ssh session.
(5) Detach from the screen (Ctrl-A d).
(6) screen freezes and is not terminated normally.

This does not occur if the user does not belong to
Administrators group.

I guess this is a problem of setuid codes.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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: Logging-in using ssh elevates the user privilege.

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

On Mar  7 01:00, Takashi Yano wrote:
> Hello,
> 
> I would like to report a problem of recent cygwin.
> 
> If a user logs in via ssh, the user aqcuires the elevated
> privilege if the user belongs to Administrators group.

This is by design, and this is no new behaviour.  As soon as an admin
account logs in, seteuid uses the elevated token.  Cygwin is doing that
since 2015.

After all, from an ssh session there would be *no* chance to run
administrative tasks if the user would only get a non-elevated token.
There's no way to switch to the elevated token from an ssh session.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Logging-in using ssh elevates the user privilege.

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Mar  6 17:15, Corinna Vinschen wrote:
> On Mar  7 01:00, Takashi Yano wrote:
> > Hello,
> > 
> > I would like to report a problem of recent cygwin.
> > 
> > If a user logs in via ssh, the user aqcuires the elevated
> > privilege if the user belongs to Administrators group.
> 
> This is by design, and this is no new behaviour.  As soon as an admin
> account logs in, seteuid uses the elevated token.  Cygwin is doing that
> since 2015.

Actually, since 2010.

> 
> After all, from an ssh session there would be *no* chance to run
> administrative tasks if the user would only get a non-elevated token.
> There's no way to switch to the elevated token from an ssh session.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Logging-in using ssh elevates the user privilege.

[Takashi Yano]

Hi Corinna,

On Wed, 6 Mar 2019 17:17:31 +0100 Corinna Vinschen wrote:
> > This is by design, and this is no new behaviour.  As soon as an admin
> > account logs in, seteuid uses the elevated token.  Cygwin is doing that
> > since 2015.
> 
> Actually, since 2010.
> 
> > After all, from an ssh session there would be *no* chance to run
> > administrative tasks if the user would only get a non-elevated token.
> > There's no way to switch to the elevated token from an ssh session.

I understood. It seems better to remove administrator privileges
from users who are normally used, even under UAC feature.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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: Logging-in using ssh elevates the user privilege.

[Achim Gratz]

Takashi Yano writes:
> I would like to report a problem of recent cygwin.
>
> If a user logs in via ssh, the user aqcuires the elevated
> privilege if the user belongs to Administrators group.

This has been the case for as long as I use ssh logins and is by design.
You can drop privileges after logon (see cygdrop), but not aquire new
ones.

So if that's changed behaviour for you, then your ssh logins didn't
actually work the way you thought they were.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: Logging-in using ssh elevates the user privilege.

[Takashi Yano]

Sorry, the message bellow accidentally lost the references.

On Thu, 7 Mar 2019 20:14:39 +0900 Takashi Yano wrote:
> On Wed, 06 Mar 2019 19:33:17 +0100 Achim Gratz wrote:
> > This has been the case for as long as I use ssh logins and is by design.
> > You can drop privileges after logon (see cygdrop), but not aquire new
> > ones.
> > 
> > So if that's changed behaviour for you, then your ssh logins didn't
> > actually work the way you thought they were.
> 
> Thank you for your reply. I had tried cygdrop, and confirmed that
> the problems below cannot be solved by cygdrop.
> 
> But I don't understand why...
> 
> On Thu, 7 Mar 2019 01:00:00 +0900 Takashi Yano wrote:
> > Because of this behaviour, the process started in a ssh
> > session cannot be killed from a normal mintty session.
> > 
> > This also causes gnu screen to freeze.
> > 
> > To reproduce this:
> > (1) Start screen in mintty window.
> > (2) Detatch from the screen (Ctrl-A d).
> > (3) Login via ssh.
> > (4) Attach screen by 'screen -r' in ssh session.
> > (5) Detach from the screen (Ctrl-A d).
> > (6) screen freezes and is not terminated normally.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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: Logging-in using ssh elevates the user privilege.

[Andrey Repin]

Greetings, Takashi Yano!

> This also causes gnu screen to freeze.

GNU screen freeze without much of an effort under Cygwin.
Try detaching from running screen and then running screen -ls.

> To reproduce this:
> (1) Start screen in mintty window.
> (2) Detatch from the screen (Ctrl-A d).
> (3) Login via ssh.
> (4) Attach screen by 'screen -r' in ssh session.
> (5) Detach from the screen (Ctrl-A d).
> (6) screen freezes and is not terminated normally.

> This does not occur if the user does not belong to
> Administrators group.

> I guess this is a problem of setuid codes.



-- 
With best regards,
Andrey Repin
Thursday, March 7, 2019 14:18:56

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: Logging-in using ssh elevates the user privilege.

[Andrey Repin]

Greetings, Takashi Yano!

>> This also causes gnu screen to freeze.

> GNU screen freeze without much of an effort under Cygwin.
> Try detaching from running screen and then running screen -ls.

Past discussion
http://sourceware.org/ml/cygwin/2017-05/msg00448.html
mid:16810313565.20170527142723@yandex.ru

>> To reproduce this:
>> (1) Start screen in mintty window.
>> (2) Detatch from the screen (Ctrl-A d).
>> (3) Login via ssh.
>> (4) Attach screen by 'screen -r' in ssh session.
>> (5) Detach from the screen (Ctrl-A d).
>> (6) screen freezes and is not terminated normally.

>> This does not occur if the user does not belong to
>> Administrators group.

>> I guess this is a problem of setuid codes.





-- 
With best regards,
Andrey Repin
Thursday, March 7, 2019 18:22:43

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: Logging-in using ssh elevates the user privilege.

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

Hello,

Thank you for the information.

On Thu, 7 Mar 2019 18:24:45 +0300 Andrey Repin wrote:
> > GNU screen freeze without much of an effort under Cygwin.
> > Try detaching from running screen and then running screen -ls.
> 
> Past discussion
> http://sourceware.org/ml/cygwin/2017-05/msg00448.html
> mid:16810313565.20170527142723@yandex.ru

I looked into this problem of GNU screen and found the
cause is very different from that of the problem I had
reported.

The problem I had reported is due to the failure of
sending signal, which is caused by mismatch of tokens
between ssh session and mintty session.

On the other hand, the problem you mentioned is due
to the difference in the behaviour of socket API.

In Linux, connect() in the client returns befor the
server calls accept(). However, in cygwin, connect()
does not return until the server calls accept().

Attached test code clarifies the difference.

[Result in Linux]
Server: Created.
Server: Binded.
Server: Listened.
Client: Created.
Client: Connected.
Client: Written.
Server: Accepted.
10: 1234567890
Server: Read.

[Result in Cygwin]
Server: Created.
Server: Binded.
Server: Listened.
Client: Created.
Server: Accepted.
Client: Connected.
Client: Written.
10: 1234567890
Server: Read.

I am not sure why cygwin behaves differently from
linux.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: sockunix.c --]
[-- Type: text/x-csrc, Size: 1701 bytes --]

#include <stdio.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/wait.h>
#include <signal.h>

#define SOCKNAME "sock_unix_test"

int main()
{
	int fd;
	struct sockaddr_un sunx;
	pid_t pid;
	ssize_t len;
	char buf[BUFSIZ];
	
	memset(&sunx, 0, sizeof(sunx));
	sunx.sun_family = AF_UNIX;
	strncpy (sunx.sun_path, SOCKNAME, sizeof(sunx.sun_path) -1 );

	pid = fork();
	if (pid) {
		int fd1;
		fd = socket(AF_UNIX, SOCK_STREAM, 0);
		printf("Server: Created.\n");
		if (fd < 0) {
			perror("socket");
			goto end_server;
		}
		if (bind(fd, (struct sockaddr *)&sunx, sizeof(sunx)) < 0) {
			perror("bind");
			goto end_server;
		}
		printf("Server: Binded.\n");
		if (listen(fd, 1) < 0) {
			perror("listen");
			goto end_server;
		}
		printf("Server: Listened.\n");

		usleep(2000000);

		fd1 = accept(fd, 0, 0);
		if (fd1 < 0) {
			perror("accept");
			goto end_server;
		}
		printf("Server: Accepted.\n");
		while ((len = read(fd1, buf, sizeof(buf))) > 0) {
			buf[len] = '\0';
			printf("%d: %s\n", len, buf);
		}
		printf("Server: Read.\n");
		close(fd1);
end_server:
		close(fd);
		kill(pid, SIGTERM);
		wait(NULL);
		if (unlink(SOCKNAME) < 0) {
			perror("unlink");
		}
	} else {
		usleep(1000000);
		fd = socket(AF_UNIX, SOCK_STREAM, 0);
		printf("Client: Created.\n");
		if (fd < 0) {
			perror("socket");
			goto end_client;
		}
		if (connect(fd, (struct sockaddr *)&sunx, sizeof(sunx)) < 0) {
			perror("connect");
			goto end_client;
		}
		printf("Client: Connected.\n");
		write(fd, "1234567890", 10);
		printf("Client: Written.\n");
end_client:
		close(fd);
	}
	
	return 0;
}


[-- Attachment #3: Type: text/plain, Size: 219 bytes --]


--
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: Logging-in using ssh elevates the user privilege.

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On Mar  8 23:01, Takashi Yano wrote:
> Hello,
> 
> Thank you for the information.
> 
> On Thu, 7 Mar 2019 18:24:45 +0300 Andrey Repin wrote:
> > > GNU screen freeze without much of an effort under Cygwin.
> > > Try detaching from running screen and then running screen -ls.
> > 
> > Past discussion
> > http://sourceware.org/ml/cygwin/2017-05/msg00448.html
> > mid:16810313565.20170527142723@yandex.ru
> 
> I looked into this problem of GNU screen and found the
> cause is very different from that of the problem I had
> reported.
> 
> The problem I had reported is due to the failure of
> sending signal, which is caused by mismatch of tokens
> between ssh session and mintty session.
> 
> On the other hand, the problem you mentioned is due
> to the difference in the behaviour of socket API.
> 
> In Linux, connect() in the client returns befor the
> server calls accept(). However, in cygwin, connect()
> does not return until the server calls accept().

This is a result of the handshake to exchange credentials for
getpeereid().  To workaround this issue, try building screen
with a tweak.  Server and as client should call

  setsockopt (sock, SOL_SOCKET, SO_PEERCRED, NULL, 0);

before calling accept or connect.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Logging-in using ssh elevates the user privilege.

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

Hi Corinna,

Thanks for your advice.

On Fri, 8 Mar 2019 15:11:18 +0100 Corinna Vinschen wrote:
> > In Linux, connect() in the client returns befor the
> > server calls accept(). However, in cygwin, connect()
> > does not return until the server calls accept().
> 
> This is a result of the handshake to exchange credentials for
> getpeereid().  To workaround this issue, try building screen
> with a tweak.  Server and as client should call
> 
>   setsockopt (sock, SOL_SOCKET, SO_PEERCRED, NULL, 0);
> 
> before calling accept or connect.

Following your advice, I tried the patch attached and
confirmed the problem regarding -Q option is solved.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: screen-peercred.patch --]
[-- Type: application/octet-stream, Size: 1467 bytes --]

--- origsrc/screen-4.6.2/socket.c	2017-10-23 20:32:41.000000000 +0900
+++ src/screen-4.6.2/socket.c	2019-03-08 23:31:11.373592400 +0900
@@ -537,6 +537,9 @@
   xseteuid(real_uid);
   xsetegid(real_gid);
 # endif
+#ifdef __CYGWIN__
+  setsockopt(s, SOL_SOCKET, SO_PEERCRED, NULL, 0);
+#endif
   if (connect(s, (struct sockaddr *) &a, strlen(SockPath) + 2) != -1)
     {
       debug("oooooh! socket already is alive!\n");
@@ -628,6 +631,9 @@
       return -1;
     }
 #endif
+#ifdef __CYGWIN__
+  setsockopt(s, SOL_SOCKET, SO_PEERCRED, NULL, 0);
+#endif
   if (connect(s, (struct sockaddr *)&a, strlen(SockPath) + 2) == -1)
     {
       if (err)
@@ -1058,6 +1064,9 @@
     {
       len = sizeof(a);
       debug("Ha, there was someone knocking on my socket??\n");
+#ifdef __CYGWIN__
+      setsockopt(ns, SOL_SOCKET, SO_PEERCRED, NULL, 0);
+#endif
       if ((ns = accept(ns, (struct sockaddr *)&a, (void *)&len)) < 0)
         {
           Msg(errno, "accept");
@@ -1308,6 +1317,9 @@
     }
   else
     {
+#ifdef __CYGWIN__
+      setsockopt(s, SOL_SOCKET, SO_PEERCRED, NULL, 0);
+#endif
       len = sizeof(a);
       s = accept(s, (struct sockaddr *)&a, (void *)&len);
       if (s < 0)
@@ -1343,6 +1355,9 @@
   if (stat(sap->sun_path, &st))
     return -1;
   chmod(sap->sun_path, 0);
+#ifdef __CYGWIN__
+  setsockopt(s, SOL_SOCKET, SO_PEERCRED, NULL, 0);
+#endif
   x = connect(s, (struct sockaddr *) sap, len);
   chmod(sap->sun_path, st.st_mode);
   return x;

[-- Attachment #3: Type: text/plain, Size: 219 bytes --]


--
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: Logging-in using ssh elevates the user privilege.

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

Hi Andrew,

On Mar  8 23:46, Takashi Yano wrote:
> Hi Corinna,
> 
> Thanks for your advice.
> 
> On Fri, 8 Mar 2019 15:11:18 +0100 Corinna Vinschen wrote:
> > > In Linux, connect() in the client returns befor the
> > > server calls accept(). However, in cygwin, connect()
> > > does not return until the server calls accept().
> > 
> > This is a result of the handshake to exchange credentials for
> > getpeereid().  To workaround this issue, try building screen
> > with a tweak.  Server and as client should call
> > 
> >   setsockopt (sock, SOL_SOCKET, SO_PEERCRED, NULL, 0);
> > 
> > before calling accept or connect.
> 
> Following your advice, I tried the patch attached and
> confirmed the problem regarding -Q option is solved.

any chance to rebuild screen with the patch from
https://cygwin.com/ml/cygwin/2019-03/msg00167.html


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Logging-in using ssh elevates the user privilege.

[Andrew Schulman]

> Hi Andrew,
> 
> On Mar  8 23:46, Takashi Yano wrote:
> > Hi Corinna,
> > 
> > Thanks for your advice.
> > 
> > On Fri, 8 Mar 2019 15:11:18 +0100 Corinna Vinschen wrote:
> > > > In Linux, connect() in the client returns befor the
> > > > server calls accept(). However, in cygwin, connect()
> > > > does not return until the server calls accept().
> > > 
> > > This is a result of the handshake to exchange credentials for
> > > getpeereid().  To workaround this issue, try building screen
> > > with a tweak.  Server and as client should call
> > > 
> > >   setsockopt (sock, SOL_SOCKET, SO_PEERCRED, NULL, 0);
> > > 
> > > before calling accept or connect.
> > 
> > Following your advice, I tried the patch attached and
> > confirmed the problem regarding -Q option is solved.
> 
> any chance to rebuild screen with the patch from
> https://cygwin.com/ml/cygwin/2019-03/msg00167.html

Sure, will do. Thanks to both of y'all for solving this.
Andrew


--
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: Logging-in using ssh elevates the user privilege.

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

On Fri, 08 Mar 2019 12:57:20 -0500 Andrew Schulman wrote:
> > any chance to rebuild screen with the patch from
> > https://cygwin.com/ml/cygwin/2019-03/msg00167.html
> 
> Sure, will do. Thanks to both of y'all for solving this.

Due to:
https://cygwin.com/ml/cygwin/2019-03/msg00176.html
the patch should be replaced by attached one.

Thank you.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: screen-peercred.patch --]
[-- Type: application/octet-stream, Size: 1171 bytes --]

--- origsrc/screen-4.6.2/socket.c	2017-10-23 20:32:41.000000000 +0900
+++ src/screen-4.6.2/socket.c	2019-03-09 00:19:12.463762700 +0900
@@ -537,6 +537,9 @@
   xseteuid(real_uid);
   xsetegid(real_gid);
 # endif
+#ifdef __CYGWIN__
+  setsockopt(s, SOL_SOCKET, SO_PEERCRED, NULL, 0);
+#endif
   if (connect(s, (struct sockaddr *) &a, strlen(SockPath) + 2) != -1)
     {
       debug("oooooh! socket already is alive!\n");
@@ -588,6 +591,9 @@
   chown(SockPath, real_uid, real_gid);
 #endif
 #endif /* SOCK_NOT_IN_FS */
+#ifdef __CYGWIN__
+  setsockopt(s, SOL_SOCKET, SO_PEERCRED, NULL, 0);
+#endif
   if (listen(s, 5) == -1)
     Panic(errno, "listen");
 #ifdef F_SETOWN
@@ -628,6 +634,9 @@
       return -1;
     }
 #endif
+#ifdef __CYGWIN__
+  setsockopt(s, SOL_SOCKET, SO_PEERCRED, NULL, 0);
+#endif
   if (connect(s, (struct sockaddr *)&a, strlen(SockPath) + 2) == -1)
     {
       if (err)
@@ -1343,6 +1352,9 @@
   if (stat(sap->sun_path, &st))
     return -1;
   chmod(sap->sun_path, 0);
+#ifdef __CYGWIN__
+  setsockopt(s, SOL_SOCKET, SO_PEERCRED, NULL, 0);
+#endif
   x = connect(s, (struct sockaddr *) sap, len);
   chmod(sap->sun_path, st.st_mode);
   return x;

[-- Attachment #3: Type: text/plain, Size: 219 bytes --]


--
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: Logging-in using ssh elevates the user privilege.

[Andrew Schulman]

> On Fri, 08 Mar 2019 12:57:20 -0500 Andrew Schulman wrote:
> > > any chance to rebuild screen with the patch from
> > > https://cygwin.com/ml/cygwin/2019-03/msg00167.html
> > 
> > Sure, will do. Thanks to both of y'all for solving this.
> 
> Due to:
> https://cygwin.com/ml/cygwin/2019-03/msg00176.html
> the patch should be replaced by attached one.

OK. I rebuilt screen 4.6.2-2 and uploaded it as a test package. Please test it
and let me know if it fixes the problem.


--
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: Logging-in using ssh elevates the user privilege.

[Takashi Yano]

Hi Adnrew,

On Fri, 08 Mar 2019 18:19:02 -0500 Andrew Schulman wrote:
> OK. I rebuilt screen 4.6.2-2 and uploaded it as a test package. Please test it
> and let me know if it fixes the problem.

I have tested screen 4.6.2-2 and confirmed the issue regarding
-Q option is solved.

Thank you for the quick response.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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: Logging-in using ssh elevates the user privilege.

[Michael Wild]

On Sat, 9 Mar 2019, 02:50 Takashi Yano wrote:

> Hi Adnrew,
>
> On Fri, 08 Mar 2019 18:19:02 -0500 Andrew Schulman wrote:
> > OK. I rebuilt screen 4.6.2-2 and uploaded it as a test package. Please
> test it
> > and let me know if it fixes the problem.
>
> I have tested screen 4.6.2-2 and confirmed the issue regarding
> -Q option is solved.
>
> Thank you for the quick response.
>

Out of curiosity, does tmux exhibit similar behavior?

Michael

>

--
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: Logging-in using ssh elevates the user privilege.

[Takashi Yano]

Hi Corinna,

On Fri, 8 Mar 2019 15:11:18 +0100 Corinna Vinschen wrote:
>   setsockopt (sock, SOL_SOCKET, SO_PEERCRED, NULL, 0);
> before calling accept or connect.

I added this to the test code but it failed as:

Server: Created.
Server: Binded.
Server: Listened.
Client: Created.
Client: Connected.
Client: Written.
accept: Software caused connection abort

Of course, setsockopt() was added also before connect().

So, I moved the setsockopt() from just before accept()
to just before listen(), then it  succeeded.

Server: Created.
Server: Binded.
Server: Listened.
Client: Created.
Client: Connected.
Client: Written.
Server: Accepted.
10: 1234567890
Server: Read.

Does this affect to listen() as well?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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: Logging-in using ssh elevates the user privilege.

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

On Mar  9 00:39, Takashi Yano wrote:
> Hi Corinna,
> 
> On Fri, 8 Mar 2019 15:11:18 +0100 Corinna Vinschen wrote:
> >   setsockopt (sock, SOL_SOCKET, SO_PEERCRED, NULL, 0);
> > before calling accept or connect.
> 
> I added this to the test code but it failed as:
> 
> Server: Created.
> Server: Binded.
> Server: Listened.
> Client: Created.
> Client: Connected.
> Client: Written.
> accept: Software caused connection abort
> 
> Of course, setsockopt() was added also before connect().
> 
> So, I moved the setsockopt() from just before accept()
> to just before listen(), then it  succeeded.
> 
> Server: Created.
> Server: Binded.
> Server: Listened.
> Client: Created.
> Client: Connected.
> Client: Written.
> Server: Accepted.
> 10: 1234567890
> Server: Read.
> 
> Does this affect to listen() as well?

No, listen isn't affected.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Logging-in using ssh elevates the user privilege.

[Takashi Yano]

On Fri, 8 Mar 2019 16:56:35 +0100 Corinna Vinschen wrote:
> > Does this affect to listen() as well?
> 
> No, listen isn't affected.

The cause is failure of setsockopt().
setsockopt() before accept() failed with EALREADY.

I looked into fhandler_sock_local.cc.

In fhandler_socket_local::af_local_set_no_getpeereid(),
connect_state() is checked if it is 'unconnected', however,
it is 'listener' after listen() is called. So it failed.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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: Logging-in using ssh elevates the user privilege.

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

On Mar  9 01:21, Takashi Yano wrote:
> On Fri, 8 Mar 2019 16:56:35 +0100 Corinna Vinschen wrote:
> > > Does this affect to listen() as well?
> > 
> > No, listen isn't affected.
> 
> The cause is failure of setsockopt().
> setsockopt() before accept() failed with EALREADY.
> 
> I looked into fhandler_sock_local.cc.
> 
> In fhandler_socket_local::af_local_set_no_getpeereid(),
> connect_state() is checked if it is 'unconnected', however,
> it is 'listener' after listen() is called. So it failed.

Yeah, right.  I misunderstood your question, sorry.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Logging-in using ssh elevates the user privilege.

[Takashi Yano]

On Wed, 06 Mar 2019 19:33:17 +0100 Achim Gratz wrote:
> This has been the case for as long as I use ssh logins and is by design.
> You can drop privileges after logon (see cygdrop), but not aquire new
> ones.
> 
> So if that's changed behaviour for you, then your ssh logins didn't
> actually work the way you thought they were.

Thank you for your reply. I had tried cygdrop, and confirmed that
the problems below cannot be solved by cygdrop.

But I don't understand why...

On Thu, 7 Mar 2019 01:00:00 +0900 Takashi Yano wrote:
> Because of this behaviour, the process started in a ssh
> session cannot be killed from a normal mintty session.
> 
> This also causes gnu screen to freeze.
> 
> To reproduce this:
> (1) Start screen in mintty window.
> (2) Detatch from the screen (Ctrl-A d).
> (3) Login via ssh.
> (4) Attach screen by 'screen -r' in ssh session.
> (5) Detach from the screen (Ctrl-A d).
> (6) screen freezes and is not terminated normally.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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