On May 8 19:17, Robert Pendell wrote:
> On Thu, May 8, 2014 at 4:09 PM, Corinna Vinschen wrote:
> > I created a new snapshot on http://cygwin.com/snapshots/ which
> > introduces the following behaviour, which is a bit less intrusive:
> >
> > If a local account is connected to a Microsoft Account,
Ken Brown cornell.edu> writes:
> This doesn't happen if you install the snapshot by the method suggested
> in the FAQ:
>
>http://cygwin.com/faq.html#faq.setup.snapshots
>
Or just make a package out of the snapshot and then install it via setup:
--8<---cut here---st
On Thu, May 8, 2014 at 8:12 PM, Ken Brown wrote:
> On 5/8/2014 7:17 PM, Robert Pendell wrote:
>>
>> On Thu, May 8, 2014 at 4:09 PM, Corinna Vinschen wrote:
>>>
>>> On May 7 16:46, Corinna Vinschen wrote:
On May 7 10:09, Chris J. Breisch wrote:
>
> Corinna Vinschen wrote:
>>
On 5/8/2014 7:17 PM, Robert Pendell wrote:
On Thu, May 8, 2014 at 4:09 PM, Corinna Vinschen wrote:
On May 7 16:46, Corinna Vinschen wrote:
On May 7 10:09, Chris J. Breisch wrote:
Corinna Vinschen wrote:
And here's a problem which I'm not sure how to solve at all:
When calling the latest mk
On Thu, May 8, 2014 at 4:09 PM, Corinna Vinschen wrote:
> On May 7 16:46, Corinna Vinschen wrote:
>> On May 7 10:09, Chris J. Breisch wrote:
>> > Corinna Vinschen wrote:
>> > >And here's a problem which I'm not sure how to solve at all:
>> > >
>> > >When calling the latest mkpasswd, the primary g
On May 7 16:46, Corinna Vinschen wrote:
> On May 7 10:09, Chris J. Breisch wrote:
> > Corinna Vinschen wrote:
> > >And here's a problem which I'm not sure how to solve at all:
> > >
> > >When calling the latest mkpasswd, the primary group of the local
> > >user account backing the Microsoft Accou
On May 7 10:09, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >And here's a problem which I'm not sure how to solve at all:
> >
> >When calling the latest mkpasswd, the primary group of the local
> >user account backing the Microsoft Account will *still* be "None".
> >
> >The reason is that
On May 7 16:20, Corinna Vinschen wrote:
> On May 7 17:53, Andrey Repin wrote:
> > Greetings, Corinna Vinschen!
> >
> > > I toyed around with the Microsoft Account a bit more. And here's why
> > > the primary group SID being identical to the user SID is not a good
> > > idea:
> >
> > > Securi
On May 7 10:05, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >I toyed around with the Microsoft Account a bit more. And here's why
> >the primary group SID being identical to the user SID is not a good
> >idea:
> >
> > Security checks.
> >
> >For instance:
> >
> > $ echo $USER
> > VM
On May 7 17:53, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
> > I toyed around with the Microsoft Account a bit more. And here's why
> > the primary group SID being identical to the user SID is not a good
> > idea:
>
> > Security checks.
>
> > For instance:
>
> > $ echo $USER
> >
Corinna Vinschen wrote:
On May 7 13:57, Corinna Vinschen wrote:
I toyed around with the Microsoft Account a bit more. And here's why
the primary group SID being identical to the user SID is not a good
idea:
Security checks.
For instance:
$ echo $USER
VMBERT8164+local_000
$ scree
Greetings, Corinna Vinschen!
> I toyed around with the Microsoft Account a bit more. And here's why
> the primary group SID being identical to the user SID is not a good
> idea:
> Security checks.
> For instance:
> $ echo $USER
> VMBERT8164+local_000
> $ screen
> Directory /tmp/uscre
Corinna Vinschen wrote:
On May 6 14:22, Chris J. Breisch wrote:
Corinna Vinschen wrote:
On Windows, users and groups are identified not by uid/gid, but by
their SID. The SID is a unique value, but other than that, a SID can
be a user or a group and in lots of cases Windows doesn't care.
A gro
On May 7 14:26, vlado99 wrote:
> On 6.5.2014 15:01, Corinna Vinschen wrote:
> >Does anybody here use a Microsoft Account on a non-English Windows system?
> >If so, I'd like to see the output of
> >
> > /cygdrive/c/Windows/System32/whoami /groups | grep S-1-11-
> >
> >What I'm especially interest
On May 7 13:57, Corinna Vinschen wrote:
> I toyed around with the Microsoft Account a bit more. And here's why
> the primary group SID being identical to the user SID is not a good
> idea:
>
> Security checks.
>
> For instance:
>
> $ echo $USER
> VMBERT8164+local_000
> $ screen
> Dir
On 6.5.2014 15:01, Corinna Vinschen wrote:
Does anybody here use a Microsoft Account on a non-English Windows system?
If so, I'd like to see the output of
/cygdrive/c/Windows/System32/whoami /groups | grep S-1-11-
What I'm especially interested in is, if the domain name,
"MicrosoftAccount" i
On May 6 14:22, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >On May 6 13:01, Chris J. Breisch wrote:
> >>Corinna Vinschen wrote:
> >>>Other than that, I'm open to discuss the necessity(?) to override
> >>>the primary group by default. But, in fact, I'm not sure this really
> >>>makes sen
Corinna Vinschen wrote:
On May 6 13:01, Chris J. Breisch wrote:
Corinna Vinschen wrote:
Other than that, I'm open to discuss the necessity(?) to override
the primary group by default. But, in fact, I'm not sure this really
makes sense. Linux systems default to creating a user-specific group
On May 6 13:01, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >Other than that, I'm open to discuss the necessity(?) to override
> >the primary group by default. But, in fact, I'm not sure this really
> >makes sense. Linux systems default to creating a user-specific group
> >account and us
Corinna Vinschen wrote:
But, here's the deal. I eventually gave up and created a Microsoft
Account on my W8.1 machine. And this was definitely the right thing to
do, for a couple of reasons:
- For a start, it uncovered a case-sensitivity bug in my new SAM/AD
account code.
- In my case `id'
On May 5 14:52, Robert Pendell wrote:
> On Mon, May 5, 2014 at 12:57 PM, Corinna Vinschen wrote:
> > alloc_sd (the underlying function creating a security descriptor) gets
> > a uid 1001 and gid 513 as input, as usual. But the owner *and* group
> > SIDs of the file's existing security descriptor
On May 6 14:52, Corinna Vinschen wrote:
> - One account in the user token's group list is a special SID for a
> user(!) account which apparently connects your local account with the
> Microsoft Account. Here's the output from Windows' own `whoami' tool:
>
> MicrosoftAccount\testu...@foob
On May 6 14:52, Corinna Vinschen wrote:
> - Alternatively, change the primary group in the Windows SAM, as
> described in the document attached to this mail. It's the latest
> version of the preliminary documentation of the new account handling
> in Cygwin. See the chapter "Cygwin
On May 5 14:56, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >alloc_sd (the underlying function creating a security descriptor) gets
> >a uid 1001 and gid 513 as input, as usual. But the owner *and* group
> >SIDs of the file's existing security descriptor is
> >S-1-5-21-3514886939-17866863
Larry Hall (Cygwin) wrote:
On 05/05/2014 06:39 PM, Chris J. Breisch wrote:
513/None is in /etc/group. It's the next to last line. The line above
is the
last line and apparently comes from some prior invocation of 'mkgroup
-c'. I
never knew until this moment that there was a 'mkgroup -c', so I
di
On 05/05/2014 06:39 PM, Chris J. Breisch wrote:
Larry Hall (Cygwin) wrote:
On 05/05/2014 06:07 PM, Chris J. Breisch wrote:
Hmmm, just noticed something in /etc/group:
Chris J. Breisch:S-1-5-21-3514886939-1786686319-3519756147-1001:11001:
and on another machine where I can reproduce this:
Chri
Larry Hall (Cygwin) wrote:
On 05/05/2014 06:07 PM, Chris J. Breisch wrote:
Hmmm, just noticed something in /etc/group:
Chris J. Breisch:S-1-5-21-3514886939-1786686319-3519756147-1001:11001:
and on another machine where I can reproduce this:
Chris:S-1-5-21-1055441198-2882714470-4103286779-1001:
On 05/05/2014 06:07 PM, Chris J. Breisch wrote:
Chris J. Breisch wrote:
Larry Hall (Cygwin) wrote:
On 05/05/2014 02:56 PM, Chris J. Breisch wrote:
Corinna Vinschen wrote:
On May 5 12:17, Chris J. Breisch wrote:
Corinna Vinschen wrote:
An strace of `chmod 400 bar' might sched some light on t
On 05/05/2014 05:57 PM, Chris J. Breisch wrote:
Larry Hall (Cygwin) wrote:
On 05/05/2014 02:56 PM, Chris J. Breisch wrote:
Corinna Vinschen wrote:
On May 5 12:17, Chris J. Breisch wrote:
Corinna Vinschen wrote:
An strace of `chmod 400 bar' might sched some light on this issue,
but I
have a g
Chris J. Breisch wrote:
Larry Hall (Cygwin) wrote:
On 05/05/2014 02:56 PM, Chris J. Breisch wrote:
Corinna Vinschen wrote:
On May 5 12:17, Chris J. Breisch wrote:
Corinna Vinschen wrote:
An strace of `chmod 400 bar' might sched some light on this issue,
but I
have a gut feeling the underlyin
Larry Hall (Cygwin) wrote:
On 05/05/2014 02:56 PM, Chris J. Breisch wrote:
Corinna Vinschen wrote:
On May 5 12:17, Chris J. Breisch wrote:
Corinna Vinschen wrote:
An strace of `chmod 400 bar' might sched some light on this issue,
but I
have a gut feeling the underlying WIndows call will not e
On 05/05/2014 02:56 PM, Chris J. Breisch wrote:
Corinna Vinschen wrote:
On May 5 12:17, Chris J. Breisch wrote:
Corinna Vinschen wrote:
An strace of `chmod 400 bar' might sched some light on this issue, but I
have a gut feeling the underlying WIndows call will not even return an
error code...
Corinna Vinschen wrote:
On May 5 12:17, Chris J. Breisch wrote:
Corinna Vinschen wrote:
An strace of `chmod 400 bar' might sched some light on this issue, but I
have a gut feeling the underlying WIndows call will not even return an
error code...
Attached. Your gut seems to be working today...
On Mon, May 5, 2014 at 12:57 PM, Corinna Vinschen wrote:
> On May 5 12:17, Chris J. Breisch wrote:
>> Corinna Vinschen wrote:
>> >On May 5 11:23, Chris J. Breisch wrote:
>> >>In both cases, I am logging on to the machine with a "Microsoft
>> >>Account": http://www.microsoft.com/en-us/account/defa
On May 5 12:17, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >On May 5 11:23, Chris J. Breisch wrote:
> >>In both cases, I am logging on to the machine with a "Microsoft
> >>Account": http://www.microsoft.com/en-us/account/default.aspx
> >
> >Hmm, maybe that's the problem. This "Microsoft
Corinna Vinschen wrote:
On May 5 11:23, Chris J. Breisch wrote:
In both cases, I am logging on to the machine with a "Microsoft
Account": http://www.microsoft.com/en-us/account/default.aspx
Hmm, maybe that's the problem. This "Microsoft Account" stuff might
influence how the underlying OS ha
On May 5 11:23, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >
> >I wasn't talking about the POSIX permissions, but about the Windows
> >ACL. In your current dir, what does `icacls .' print? Maybe that
> >gives a clue.
>
> Mea culpa. I should read better. I could have included that the l
Corinna Vinschen wrote:
I wasn't talking about the POSIX permissions, but about the Windows
ACL. In your current dir, what does `icacls .' print? Maybe that
gives a clue.
Mea culpa. I should read better. I could have included that the last time.
$ icacls .
. WIN8-VM\Chris:(F)
BUILTIN\User
On May 5 10:17, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >On May 5 09:49, Chris J. Breisch wrote:
> >As far as Cygwin tools are concerned, the None group is just a normal
> >group like any other group. The behaviour you're observing looks a bit
> >like either your group file is not ok
Corinna Vinschen wrote:
On May 5 09:49, Chris J. Breisch wrote:
As far as Cygwin tools are concerned, the None group is just a normal
group like any other group. The behaviour you're observing looks a bit
like either your group file is not ok, or you're testing this with the
noacl mount option.
On May 5 09:49, Chris J. Breisch wrote:
> Hi,
>
> I noticed this over the weekend. It's probably working as designed,
> however. And may have even been noticed by others before.
>
> As has been noted in the past, if your machine is not a Domain
> member, your account gets assigned to the "None"
Hi,
I noticed this over the weekend. It's probably working as designed,
however. And may have even been noticed by others before.
As has been noted in the past, if your machine is not a Domain member,
your account gets assigned to the "None" group. And it's your default
group as well. The pr
42 matches
Mail list logo