This is the mail archive of the
mailing list for the Cygwin project.
Re: Problems with screen on Windows 10 Preview system
- From: Stephen John Smoogen <smooge at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Sat, 2 May 2015 11:51:37 -0600
- Subject: Re: Problems with screen on Windows 10 Preview system
- Authentication-results: sourceware.org; auth=none
- References: <CANnLRdjiHWKS8VBzTs0dh5K3h+3raffCeDN-JBu+HHic+FduVA at mail dot gmail dot com> <20150502134701 dot GC12723 at calimero dot vinschen dot de>
On 2 May 2015 at 07:47, Corinna Vinschen <firstname.lastname@example.org> wrote:
> On May 1 17:32, Stephen John Smoogen wrote:
>> I downloaded and installed a copy of Windows 10 on a spare system to
>> see how Cygwin works. Most of the applications worked similarly to
>> what I was testing on my Windows 7 system. However I have run into a
>> problem with the screen command.
>> The first time I run screen the command gives me a standard help
>> screen and data. If I type exit to get back to mintty and then
>> type screen again.. I get:
>> Directory '/tmp/uscreens' must have mode 777.
>> Which after going through the faq and old mailing list was
>> something that occurred on FAT partitions. So I went to check the
>> install and the file format is NTFS. I then looked at /tmp and
>> drwx---rwt+ 1 smoog smoog 0 May 1 16:01 uscreens
> You're using a "Microsoft Account", one of those for twhich the primary
> group SID is set to the same SID as your user account has. So
> uid==gid==the exact same SID. The group "smoog" is NOT a group called
> "smoog", it's your user account. This leads to a chicken-egg problem:
Oooooh that explains a lot. I was figuring there was an issue with my
account but I wasn't sure if this was a new one due to Windows 10
preview, or something I didn't know about Windows account systems.
[Time to get a book on deep Windows internals and administration.]
> Either Cygwin sets the group permissions in the POSIX permission
> attributes to the same value as the user permissions, e.g.
> then security-sensitive POSIX applications will complain that the
> permissions are too wide-open.
> Or, Cygwin sets the group permissions to 0, e.g.
> Then, apparently, screen complains.
> There would be a third way, which is, to spill the "other" permissions
> into the group permissions, in my example:
> That should work, but needs YA patch to Cygwin and needs some testing.
> Bad timing right now (vaca).
> Workaround: Set the primary group to the affected files explicitely to
> an existing group which is in your user token. That would typically be
> the group "users", e.g.
> chgrp users /tmp/uscreens
> should work, and then you can chmod it and screen should stop
Thank you for answering while you are on vacation. I am going to see
if a /etc/passwd and /etc/group entry to better fix that long term.
> Corinna Vinschen Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat
Stephen J Smoogen.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple