/usr/local, /var and */tmp in c:\Users\Public

/usr/local, /var and */tmp in c:\Users\Public

[Warren Young]

I didn’t want to derail the discussion about the future of /home with this, so I’m starting a new thread.

I think it would be an improvement to Cygwin if c:\cygwin contained only things that can be reinstalled from your local setup.exe download cache, in the same way that you can nuke "c:\Program Files\Microsoft Office $version” and reinstall without losing anything you created locally.

Further design principles follow from this:

- User data should live in directories that those users are normally allowed to write to.

- Per-machine software and per-machine configuration should be in directories that local Administrators can normally write to.

- Software built from source (/usr/local) should not be in c:\cygwin; it is per-machine configuration, and so should be elsewhere.

- If you tighten down what remains so that normal users only get read permission, it should continue to function, in the same way that normal users on a Linux box don’t need write access to, say, /usr/include.


This /etc/fstab addition mostly accomplishes that:


c:/Users/Public/Cygwin/var         /var         ntfs   auto      0 0
c:/Users/Public/Cygwin/usr/local   /usr/local   ntfs   auto      0 0

c:/Users/Public/Cygwin/tmp         /tmp         ntfs   notexec   0 0
c:/Users/Public/Cygwin/tmp         /usr/tmp     ntfs   notexec   0 0
c:/Users/Public/Cygwin/tmp         /var/tmp     ntfs   notexec   0 0


I propose that this or something like it be added to the default fstab.

It should apply to an existing setup without trouble.  If you already have things in /var and /usr/local, you should copy those trees over first.

The only thing remaining in c:\cygwin that can’t be moved in this way — but which it would be nice to — is /etc.  If you try, you will find that it makes Cygwin asplode; cygwin1.dll needs to find $cygbindir/../etc in order to find /etc/fstab, at the least.

Attempting to create a “shadow /etc” — vaguely like how Linux’s initrd works — also failed here, but it doesn’t seem like a good idea to do this anyway.  It means you now have to remember which of the two etc dirs to edit files in, a management hassle I don’t want.

(Anyone who uses FreeBSD with Ports installed knows this pain, with /etc and /usr/local/etc.  In Cygwin, it would be /etc and /cygdrive/c/cygwin/etc.)

Are there any directories I have missed?
--
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: /usr/local, /var and */tmp in c:\Users\Public

[cyg Simple]

On Wed, Nov 12, 2014 at 1:00 PM, Warren Young wrote:
> I didn’t want to derail the discussion about the future of /home with this, so I’m starting a new thread.
>
> I think it would be an improvement to Cygwin if c:\cygwin contained only things that can be reinstalled from your local setup.exe download cache, in the same way that you can nuke "c:\Program Files\Microsoft Office $version” and reinstall without losing anything you created locally.
>

What local changes/installations get lost?

> Further design principles follow from this:
>
> - User data should live in directories that those users are normally allowed to write to.
>
> - Per-machine software and per-machine configuration should be in directories that local Administrators can normally write to.
>
> - Software built from source (/usr/local) should not be in c:\cygwin; it is per-machine configuration, and so should be elsewhere.
>
> - If you tighten down what remains so that normal users only get read permission, it should continue to function, in the same way that normal users on a Linux box don’t need write access to, say, /usr/include.
>
>
> This /etc/fstab addition mostly accomplishes that:
>
>
> c:/Users/Public/Cygwin/var         /var         ntfs   auto      0 0
> c:/Users/Public/Cygwin/usr/local   /usr/local   ntfs   auto      0 0
>
> c:/Users/Public/Cygwin/tmp         /tmp         ntfs   notexec   0 0
> c:/Users/Public/Cygwin/tmp         /usr/tmp     ntfs   notexec   0 0
> c:/Users/Public/Cygwin/tmp         /var/tmp     ntfs   notexec   0 0
>
>
> I propose that this or something like it be added to the default fstab.
>

Please NO not by default or offering an option.  A back end tool maybe
in cygutils that can be run manually.

-- 
cyg 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: /usr/local, /var and */tmp in c:\Users\Public

[Warren Young]

On Nov 12, 2014, at 2:53 PM, cyg Simple <cygsimple@gmail.com> wrote:

> On Wed, Nov 12, 2014 at 1:00 PM, Warren Young wrote:
>> 
>> I think it would be an improvement to Cygwin if c:\cygwin contained only things that can be reinstalled from your local setup.exe download cache, in the same way that you can nuke "c:\Program Files\Microsoft Office $version” and reinstall without losing anything you created locally.
>> 
> 
> What local changes/installations get lost?

Currently, if you nuke a default installation into c:\cygwin, you lose /home, /etc, /var and /usr/local, all of which contain user files and/or local system configuration.

Step 4 in the recommended uninstallation sequence[1] doesn't warn about this.  I guess the thought there is that if you’re uninstalling Cygwin, you probably just installed it recently and decided you don’t want it.

Apparently those of us who have been using Cygwin for years and just need to do a clean reinstall for some reason are expected to know enough not to take step 4 too literally.

(Indeed, I have never nuked myself this way.  Still, it seems a bit of an oversight.)

> Please NO not by default or offering an option.  A back end tool maybe
> in cygutils that can be run manually.

Are you just asking me not to move your cheese[2], or do you have a specific problem with this, which we could discuss?

How does it help you to have user files intermixed with system files?  Do you save documents into c:\Program Files, too?


[1] https://cygwin.com/faq/faq.html#faq.setup.uninstall-all
[2] https://en.wikipedia.org/wiki/Who_Moved_My_Cheese%3F
--
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: /usr/local, /var and */tmp in c:\Users\Public

[Andrew DeFaria]

On 11/12/2014 2:16 PM, Warren Young wrote:
>> What local changes/installations get lost?
>
> Currently, if you nuke a default installation into c:\cygwin, you lose /home, /etc, /var and /usr/local, all of which contain user files and/or local system configuration.

Technically user files can exist anywhere in the file system, including 
C:\cygwin or /etc, /var, etc., or they could be put directly into /bin, 
/usr or /usr/sbin or whatever. You're just saying that *traditionally* 
these are the areas that *smart* users limit their local changes too.

It's a nice guideline but there are no guarantees...

> Apparently those of us who have been using Cygwin for years and just need to do a clean reinstall for some reason are expected to know enough not to take step 4 too literally.

I've been using Cygwin since 2003 (does that qualify me?) and have never 
feel the need to reinstall. However, as a contractor I've often had the 
need to install again...
-- 
Andrew DeFaria
http://defaria.com


--
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: /usr/local, /var and */tmp in c:\Users\Public

[Warren Young]

On Nov 12, 2014, at 3:43 PM, Andrew DeFaria <Andrew@DeFaria.com> wrote:

> On 11/12/2014 2:16 PM, Warren Young wrote:
>>> What local changes/installations get lost?
>> 
>> Currently, if you nuke a default installation into c:\cygwin, you lose /home, /etc, /var and /usr/local, all of which contain user files and/or local system configuration.
> 
> Technically user files can exist anywhere in the file system

All the more reason to move to a world where it’s possible to start securing /usr/bin, /usr/lib, /usr/share… so that only setup.exe can write to it.

I’m not advocating that step so early, but maybe if this breakup does happen, a few years later setup.exe can start applying some strong ACLs to files it writes.

>> Apparently those of us who have been using Cygwin for years and just need to do a clean reinstall for some reason are expected to know enough not to take step 4 too literally.
> 
> I've been using Cygwin since 2003 (does that qualify me?) and have never feel the need to reinstall.

While doing the “size of Cygwin” research, I managed to stuff up my installation badly enough to need a reinstall a few times. :)

   http://stackoverflow.com/questions/21230657/

I’m not sure I’ve had to reinstall more often than for PC upgrades and such previously.

This proposed change should also allow Windows 8+’s File History feature to back up Cygwin user files.  It only backs up files that are in places normal users *should* be writing files.

   http://www.howtogeek.com/74623/

(File History is more or less Microsoft’s clone of Apple’s wonderful Time Machine feature.  And yes, I’m aware that not everyone thinks the feature is wonderful.)
--
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: /usr/local, /var and */tmp in c:\Users\Public

[Corinna Vinschen]

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

On Nov 12 17:19, Warren Young wrote:
> On Nov 12, 2014, at 3:43 PM, Andrew DeFaria <Andrew@DeFaria.com>
> wrote:
> 
> > On 11/12/2014 2:16 PM, Warren Young wrote:
> >>> What local changes/installations get lost?
> >> 
> >> Currently, if you nuke a default installation into c:\cygwin, you
> >> lose /home, /etc, /var and /usr/local, all of which contain user
> >> files and/or local system configuration.
> > 
> > Technically user files can exist anywhere in the file system
> 
> All the more reason to move to a world where it’s possible to start
> securing /usr/bin, /usr/lib, /usr/share… so that only setup.exe can
> write to it.
> 
> I’m not advocating that step so early, but maybe if this breakup does
> happen, a few years later setup.exe can start applying some strong
> ACLs to files it writes.

??? What "strong" ACLs?  Setup creates the files with standard POSIX
permissions.  Which permissions are too open from your POV?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: /usr/local, /var and */tmp in c:\Users\Public

[Warren Young]

On Nov 13, 2014, at 2:33 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:

> On Nov 12 17:19, Warren Young wrote:
>> 
>> I’m not advocating that step so early, but maybe if this breakup does
>> happen, a few years later setup.exe can start applying some strong
>> ACLs to files it writes.
> 
> ??? What "strong" ACLs?

The ones that are not there right now. :)

Just to pick a random example:

$ ls -l /bin/ls.exe
-rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe

The same file’s permissions, from Windows’ perspective:

http://etr-usa.com/cygwin/ls-perms.png

So, just because I installed Cygwin with my regular user account, I get permission to rewrite ls.exe.  This is not a good thing, if our goal is to make Cygwin work like Linux while working *within* the Windows environment.  

IMHO, the way to meet both goals simultaneously is to put programs in c:\Program Files, and to give full-control perms to the local Administrator account in the SAM case, or possibly the domain one in the AD case.
--
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: /usr/local, /var and */tmp in c:\Users\Public

[Corinna Vinschen]

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

On Nov 13 14:09, Warren Young wrote:
> On Nov 13, 2014, at 2:33 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > On Nov 12 17:19, Warren Young wrote:
> >> 
> >> I’m not advocating that step so early, but maybe if this breakup does
> >> happen, a few years later setup.exe can start applying some strong
> >> ACLs to files it writes.
> > 
> > ??? What "strong" ACLs?
> 
> The ones that are not there right now. :)
> 
> Just to pick a random example:
> 
> $ ls -l /bin/ls.exe
> -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe
> 
> The same file’s permissions, from Windows’ perspective:
> 
> http://etr-usa.com/cygwin/ls-perms.png

icacls output would be more helpful than a picture.

However, this isn't really a problem.  The group permissions are
apparently faked by Cygwin, they don't reflect the reality.  I just
don't remember why this is done, it's probably old.  Have to check...

> So, just because I installed Cygwin with my regular user account, I
> get permission to rewrite ls.exe.  This is not a good thing, if our
> goal is to make Cygwin work like Linux while working *within* the
> Windows environment.  

> IMHO, the way to meet both goals simultaneously is to put programs in
> c:\Program Files,

No, sorry, but no.  We're certainly not going to turn everything upside
down installation-wise.  If you want Cygwin installed into Program
Files, just change it in the GUI.

> and to give full-control perms to the local
> Administrator account in the SAM case, or possibly the domain one in
> the AD case.

BTDT.  The code is still in Setup, just doesn't run anymore.  The idea
was to install with user and group set to Administator/ Administrators,
but we had some complaints and the code got deactivated.  We can
reactivate the Administrators group, but that still requires to run
Setup elevated.  It doesn't work when running under a non-admin account.

However, the *other* idea is that if you install with an elevated Setup,
your account is an admin account anyway.  Ideally when you install
Cygwin for multiple users, you're using an account you're not using for
daily usage.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: /usr/local, /var and */tmp in c:\Users\Public

[Warren Young]

On Nov 13, 2014, at 2:30 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:

> On Nov 13 14:09, Warren Young wrote:
>> 
>> http://etr-usa.com/cygwin/ls-perms.png
> 
> icacls output would be more helpful than a picture.

$ icacls ls.exe
ls.exe MOSSYMAZE\Warren:(F)
       MOSSYMAZE\Warren:(RX)
       Everyone:(RX)

> It doesn't work when running under a non-admin account.

Every other Windows setup program is playing by that same restriction.

> However, the *other* idea is that if you install with an elevated Setup,
> your account is an admin account anyway.  Ideally when you install
> Cygwin for multiple users, you're using an account you're not using for
> daily usage.

Couldn’t the Cygwin non-user files be owned by SYSTEM instead of the installing user?
--
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: /usr/local, /var and */tmp in c:\Users\Public

[Corinna Vinschen]

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

On Nov 13 14:39, Warren Young wrote:
> On Nov 13, 2014, at 2:30 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > On Nov 13 14:09, Warren Young wrote:
> >> 
> >> http://etr-usa.com/cygwin/ls-perms.png
> > 
> > icacls output would be more helpful than a picture.
> 
> $ icacls ls.exe
> ls.exe MOSSYMAZE\Warren:(F)
>        MOSSYMAZE\Warren:(RX)
>        Everyone:(RX)
> 
> > It doesn't work when running under a non-admin account.
> 
> Every other Windows setup program is playing by that same restriction.

Setup tries to install with (explicit) POSIX permissions, not with
(inherited) Windows permissions.  It's not quite the same thing.

> > However, the *other* idea is that if you install with an elevated Setup,
> > your account is an admin account anyway.  Ideally when you install
> > Cygwin for multiple users, you're using an account you're not using for
> > daily usage.
> 
> Couldn’t the Cygwin non-user files be owned by SYSTEM instead of the installing user?

In a corporate model this might make sense, but for the home user?  I'm
not so sure about SYSTEM, though.  Administrator/Administrators sounds
right to me.  SYSTEM?  Hmm.  As I said, at one point back in the early
1.7 days setup did something like that, but we got complaints.  I don't
remember the details.  But if we do something like that again, it should
be configurable.  Maybe the "Just Me"/"All users" choice is sufficient
if explained sufficiently in the GUI?

Also, who's going to do that?  The coding part, I mean.  Lots of what's
required is already in setup, but I can't write it often enough (it's
an obsession probably): I would be very glad for developers not shy
making their hands dirty.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: /usr/local, /var and */tmp in c:\Users\Public

[Andrey Repin]

Greetings, Corinna Vinschen!

>> > However, the *other* idea is that if you install with an elevated Setup,
>> > your account is an admin account anyway.  Ideally when you install
>> > Cygwin for multiple users, you're using an account you're not using for
>> > daily usage.
>> 
>> Couldn’t the Cygwin non-user files be owned by SYSTEM instead of the installing user?

> In a corporate model this might make sense, but for the home user?  I'm
> not so sure about SYSTEM, though.  Administrator/Administrators sounds
> right to me.  SYSTEM?

NT SERVICE\TrustedInstaller >.<
At least that's what many of the apps installed with.

@ /c/Program Files/DVD Maker
$ icacls DVDMaker.exe | iconv -f cp866
DVDMaker.exe NT SERVICE\TrustedInstaller:(F)
             BUILTIN\Administrators:(RX)
             NT AUTHORITY\SYSTEM:(RX)
             BUILTIN\Users:(RX)

Not all, though.

@ /c/Program Files/Opera
$ icacls.exe opera.exe | iconv -f cp866
opera.exe NT AUTHORITY\SYSTEM:(I)(F)
          BUILTIN\Administrators:(I)(F)
          BUILTIN\Users:(I)(RX)

> Hmm.  As I said, at one point back in the early
> 1.7 days setup did something like that, but we got complaints.  I don't
> remember the details.  But if we do something like that again, it should
> be configurable.  Maybe the "Just Me"/"All users" choice is sufficient
> if explained sufficiently in the GUI?

It's interested to know, what these complaints were about exactly. I was away
from the list, when transition to 1.7 occured.

> Also, who's going to do that?  The coding part, I mean.  Lots of what's
> required is already in setup, but I can't write it often enough (it's
> an obsession probably): I would be very glad for developers not shy
> making their hands dirty.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 14.11.2014, <02:02>

Sorry for my terrible english...

Re: /usr/local, /var and */tmp in c:\Users\Public

[Corinna Vinschen]

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

On Nov 13 22:30, Corinna Vinschen wrote:
> On Nov 13 14:09, Warren Young wrote:
> > On Nov 13, 2014, at 2:33 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> > 
> > > On Nov 12 17:19, Warren Young wrote:
> > >> 
> > >> I’m not advocating that step so early, but maybe if this breakup does
> > >> happen, a few years later setup.exe can start applying some strong
> > >> ACLs to files it writes.
> > > 
> > > ??? What "strong" ACLs?
> > 
> > The ones that are not there right now. :)
> > 
> > Just to pick a random example:
> > 
> > $ ls -l /bin/ls.exe
> > -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe
> > 
> > The same file’s permissions, from Windows’ perspective:
> > 
> > http://etr-usa.com/cygwin/ls-perms.png
> 
> icacls output would be more helpful than a picture.
> 
> However, this isn't really a problem.  The group permissions are
> apparently faked by Cygwin, they don't reflect the reality.  I just
> don't remember why this is done, it's probably old.  Have to check...

Btw., I never saw this happen.  Did you install for "just you", or
in a non-elevated Setup?  In my case the permissions make at least
sense, even if my own account still has full access:

  $ ls -l /bin/ls.exe
  -rwxr-xr-x 1 corinna vinschen 116253 Oct 13 18:12 /bin/ls.exe


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: /usr/local, /var and */tmp in c:\Users\Public

[Warren Young]

On Nov 13, 2014, at 3:09 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:

> Did you install for "just you",

I just made a fresh install into c:\zz, accepting all the defaults in setup.exe, so it installed for everyone.  I got the same result as my preexisting install.

Perhaps this is helpful:

$ id
uid=1000(Warren) gid=513(None) groups=513(None),559(Performance Log Users),545(Users)

Apparently I am a member of both None and Users, whatever that means.

> or in a non-elevated Setup?

I did these tests on a Windows 10 technical preview VM with UAC left in its default setting.  I did get the blue and yellow UAC dimmed desktop dialog when running setup.exe, so I assume it managed to elevate itself.
--
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: /usr/local, /var and */tmp in c:\Users\Public

[Corinna Vinschen]

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

On Nov 13 15:20, Warren Young wrote:
> On Nov 13, 2014, at 3:09 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > Did you install for "just you",
> 
> I just made a fresh install into c:\zz, accepting all the defaults in setup.exe, so it installed for everyone.  I got the same result as my preexisting install.
> 
> Perhaps this is helpful:
> 
> $ id
> uid=1000(Warren) gid=513(None) groups=513(None),559(Performance Log Users),545(Users)
> 
> Apparently I am a member of both None and Users, whatever that means.

That's normal.  No idea what "they" thought by introducing the local
"None" group.  It's your primary group with every local SAM account,
unchangable in the user management.

> > or in a non-elevated Setup?
> 
> I did these tests on a Windows 10 technical preview VM with UAC left
> in its default setting.  I did get the blue and yellow UAC dimmed
> desktop dialog when running setup.exe, so I assume it managed to
> elevate itself.

Weird.  I wonder why the ACL doesn't contain your primary group.  Setup
installs all files with explicit ACL containing entries for you, your
primary group, and "Everyone".


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: /usr/local, /var and */tmp in c:\Users\Public

[Andrey Repin]

Greetings, Corinna Vinschen!

>> > Just to pick a random example:
>> > 
>> > $ ls -l /bin/ls.exe
>> > -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe
>> > 
>> > The same file’s permissions, from Windows’ perspective:
>> > 
>> > http://etr-usa.com/cygwin/ls-perms.png
>> 
>> icacls output would be more helpful than a picture.
>> 
>> However, this isn't really a problem.  The group permissions are
>> apparently faked by Cygwin, they don't reflect the reality.  I just
>> don't remember why this is done, it's probably old.  Have to check...

> Btw., I never saw this happen.  Did you install for "just you", or
> in a non-elevated Setup?  In my case the permissions make at least
> sense, even if my own account still has full access:

>   $ ls -l /bin/ls.exe
>   -rwxr-xr-x 1 corinna vinschen 116253 Oct 13 18:12 /bin/ls.exe

Curious. Same for me.
Win7/64 with 64-bit Cygwin default (elevated) install.


$ LANG=C ls -l /bin/ls
-rwxr-xr-x 1 anrdaemon None 116253 Oct 13 19:12 /bin/ls

$ LANG=C ls -l /bin/ls.exe
-rwxr-xr-x 1 anrdaemon None 116253 Oct 13 19:12 /bin/ls.exe


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 14.11.2014, <02:13>

Sorry for my terrible english...

Re: /usr/local, /var and */tmp in c:\Users\Public

[Shaddy Baddah]

Hi,

On 14/11/14 08:30, Corinna Vinschen wrote:
> On Nov 13 14:09, Warren Young wrote:
>> On Nov 13, 2014, at 2:33 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
>>
>>> On Nov 12 17:19, Warren Young wrote:
>>>>
>>>> I’m not advocating that step so early, but maybe if this breakup does
>>>> happen, a few years later setup.exe can start applying some strong
>>>> ACLs to files it writes.
>>>
>>> ??? What "strong" ACLs?
>>
>> The ones that are not there right now. :)
>>
>> Just to pick a random example:
>>
>> $ ls -l /bin/ls.exe
>> -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe
>>
>> The same file’s permissions, from Windows’ perspective:
>>
>> http://etr-usa.com/cygwin/ls-perms.png
>
> icacls output would be more helpful than a picture.
>
> However, this isn't really a problem.  The group permissions are
> apparently faked by Cygwin, they don't reflect the reality.  I just
> don't remember why this is done, it's probably old.  Have to check...
>
>> So, just because I installed Cygwin with my regular user account, I
>> get permission to rewrite ls.exe.  This is not a good thing, if our
>> goal is to make Cygwin work like Linux while working *within* the
>> Windows environment.
>
>> IMHO, the way to meet both goals simultaneously is to put programs in
>> c:\Program Files,
>
> No, sorry, but no.  We're certainly not going to turn everything upside
> down installation-wise.  If you want Cygwin installed into Program
> Files, just change it in the GUI.
>
>> and to give full-control perms to the local
>> Administrator account in the SAM case, or possibly the domain one in
>> the AD case.
>
> BTDT.  The code is still in Setup, just doesn't run anymore.  The idea
> was to install with user and group set to Administator/ Administrators,
> but we had some complaints and the code got deactivated.  We can
> reactivate the Administrators group, but that still requires to run
> Setup elevated.  It doesn't work when running under a non-admin account.
>
> However, the *other* idea is that if you install with an elevated Setup,
> your account is an admin account anyway.  Ideally when you install
> Cygwin for multiple users, you're using an account you're not using for
> daily usage.

If you read back through some of my emails to this list, you'll see that
this is exactly the setup I adopted some time back. It is also why I
contributed the -B switch to setup.

What the OP is asking for has always been available. And it is
analogous with Unix.

What I do is:

1) create a non-admin user named portapps.
2) cmd
3) runas /user:portapps cmd
4) as portapps, run c:\Program Files\7zip\7zFM to give me a graphical
    way to navigate the filesystem and create folders.
5) Create a folder c:\Users\Public\portapps.
6) Adjust the permissions on that folder so that inheritance from
    c:\Users\Public is broken, and inherited permissions with portapps
    FullControl and Everyone read/execute (I'm talking Windows perms
    here).
7) Now I run setup-x86(_64) -B still as portapps from cmd, install to
    c:\User\Public\portapps\cygwin.
8) That's it. Now my regular user can run
    c:\User\Public\portapps\cygwin\bin\mintty - and cannot accidentally
    overwrite /bin, /etc or anything like that. All software
    administration (install, /etc config) is done via portapps user.
9) This is no different to unix/linux, where you'd have to do
    sudo apt-get install, or sudo yum install, or sudo vi /etc/profile
    etc.... portapps is almost equal to root.
10) If you want to do Windows privileged stuff, you'll have to run
    those in an elevated mintty. Of course there is still the danger of
    overwriting /bin there. But if you are limiting doing that to just
    things like ssh-host-config etc, than it's fine. Also best to have
    a separate admin account to your account if possible.

-- 
Regards,
Shaddy


--
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: /usr/local, /var and */tmp in c:\Users\Public

[Lee]

On 11/13/14, Warren Young   wrote:
> On Nov 13, 2014, at 2:33 AM, Corinna Vinschen wrote:
>
>> On Nov 12 17:19, Warren Young wrote:
>>>
>>> I'm not advocating that step so early, but maybe if this breakup does
>>> happen, a few years later setup.exe can start applying some strong
>>> ACLs to files it writes.
>>
>> ??? What "strong" ACLs?
>
> The ones that are not there right now. :)
>
> Just to pick a random example:
>
> $ ls -l /bin/ls.exe
> -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe

Install cygwin as an admin & users don't get write access:
$ ls -l /bin/ls.exe
-rwxr-xr-x 1 root None 101902 Feb  6  2012 /bin/ls.exe


> The same file's permissions, from Windows' perspective:
>
> http://etr-usa.com/cygwin/ls-perms.png
>
> So, just because I installed Cygwin with my regular user account,

You're doing it wrong.  Install Cygwin using an admin account and
regular user accounts are not allowed write access to system
files/directories:

$ cd /bin

/bin
$ touch foo
touch: cannot touch `foo': Permission denied

/bin
$ cd /usr

/usr
$ touch foo
touch: cannot touch `foo': Permission denied

> I get
> permission to rewrite ls.exe.  This is not a good thing,

In certain circumstances you're right; not a good thing.  If you have
an admin account on the machine, why didn't you install cygwin using
that account & have the permissions set correctly in the first place?
In other circumstances, like not having an admin account, it's nice
being able to install & use cygwin as a regular user vs. not having
access to cygwin at all.


> if our goal is to
> make Cygwin work like Linux while working *within* the Windows environment.
>
>
> IMHO, the way to meet both goals simultaneously is to put programs in
> c:\Program Files,

NOOOOOOOOOOOO!  Please, do not do that by default.  If nothing else,
directory names with embedded spaces should be treated like toxic
waste.

> and to give full-control perms to the local Administrator
> account in the SAM case, or possibly the domain one in the AD case.

Try installing cygwin as an admin.  I suspect you'll get most, if not
all, of what you're asking for.

Regards,
Lee

--
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: /usr/local, /var and */tmp in c:\Users\Public

[Jeffrey Altman]

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

On 11/15/2014 12:55 PM, Lee wrote:

>> So, just because I installed Cygwin with my regular user account,
> 
> You're doing it wrong.  Install Cygwin using an admin account and
> regular user accounts are not allowed write access to system
> files/directories:

This feels really wrong to me.  If installing Cygwin under a non-admin
account results in a potential security vulnerability, then the
installer should be taking that into account.  Applications that behave
differently depending upon how they are installed should have in the
installer an option for

 * install for all users (requires administrator)

 * install for the current user

Where install for current user installs the application configured so
that the current user account (and not others) can use it.

Just my two cents.

Jeffrey Altman



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4529 bytes --]

Re: /usr/local, /var and */tmp in c:\Users\Public

[Lee]

On 11/15/14, Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
> On 11/15/2014 12:55 PM, Lee wrote:
>
>>> So, just because I installed Cygwin with my regular user account,
>>
>> You're doing it wrong.  Install Cygwin using an admin account and
>> regular user accounts are not allowed write access to system
>> files/directories:
>
> This feels really wrong to me.  If installing Cygwin under a non-admin
> account results in a potential security vulnerability, then the
> installer should be taking that into account.

I would argue that no, the installer should _not_ take that into
account.  If someone wants to install cygwin under their regular
userid, why should the installer try to work around that?  The files
are installed with the "correct" permissions if the windows admin has
an administrator account for doing admin chores & a regular user
account for doing day to day user tasks.


>  Applications that behave
> differently depending upon how they are installed

It's the file permissions that are different.  As far as I can tell,
cygwin behaves the same when installed by a user for the current user
& when installed as an admin for all users.

> should have in the
> installer an option for
>
>  * install for all users (requires administrator)
>
>  * install for the current user

Which the cygwin installer does do.  It's up to the user that wants
the more secure file permissions to install cygwin using an admin
account & have another account for normal day to day use.

Best Regards,
Lee


> Where install for current user installs the application configured so
> that the current user account (and not others) can use it.
>
> Just my two cents.
>
> Jeffrey Altman
>
>
>

--
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: /usr/local, /var and */tmp in c:\Users\Public

[cyg Simple]

On Sat, Nov 15, 2014 at 1:41 PM, Lee wrote:
> On 11/15/14, Jeffrey Altman wrote:
>> On 11/15/2014 12:55 PM, Lee wrote:
>>
>>>> So, just because I installed Cygwin with my regular user account,
>>>
>>> You're doing it wrong.  Install Cygwin using an admin account and
>>> regular user accounts are not allowed write access to system
>>> files/directories:
>>
>> This feels really wrong to me.  If installing Cygwin under a non-admin
>> account results in a potential security vulnerability, then the
>> installer should be taking that into account.
>
> I would argue that no, the installer should _not_ take that into
> account.  If someone wants to install cygwin under their regular
> userid, why should the installer try to work around that?  The files
> are installed with the "correct" permissions if the windows admin has
> an administrator account for doing admin chores & a regular user
> account for doing day to day user tasks.

Because a user who is using a corporate laptop with administrator
accounts locked down would not be able to install Cygwin.

Because a user who is used to having ownership of the files he
installs would become frustrated that he could not remove Cygwin by
simply opening the Windows explorer, picking his way to the Cygwin
root folder, right clicking it and saying Delete.

Because this list would become overrun with queries of why can't I add
a program from an archive to the /usr/bin directory or remove or ...

An install "Only for the user" should not create such locked down
control of the system without asking.  Some users tend to know what to
do and what not to do and do not want the extra measures to protect
themselves.

-- 
cyg 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: /usr/local, /var and */tmp in c:\Users\Public

[Warren Young]

On Nov 15, 2014, at 10:55 AM, Lee <ler762@gmail.com> wrote:

> On 11/13/14, Warren Young   wrote:
>> I installed Cygwin with my regular user account,
> 
> You're doing it wrong.  Install Cygwin using an admin account and
> regular user accounts are not allowed write access to system
> files/directories:

While my idea does have applicability to multi-user Windows systems, I also want it to work without using Admin gymnastics on a single-user Windows system.

That is, I want this:

    $ echo -n "" >> /usr/bin/vi

to fail just as this does:

    $ echo -n "" >> /cygdrive/c/Windows/notepad.exe
    -bash: /cygdrive/c/Windows/notepad.exe: Permission denied

I want them both to fail for the same reason: normal users — whether they are members of group Administrators or not — have no business writing to system files.  Only the installer process (Cygwin Setup in this case) should be able to do that.

For what it’s worth:

$ cd /cygdrive/c/Windows
$ icacls notepad.exe
notepad.exe NT SERVICE\TrustedInstaller:(F)
            BUILTIN\Administrators:(RX)
            NT AUTHORITY\SYSTEM:(RX)
            BUILTIN\Users:(RX)
            APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(RX)


--
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: /usr/local, /var and */tmp in c:\Users\Public

[cyg Simple]

On Wed, Nov 12, 2014 at 5:16 PM, Warren Young wrote:
> On Nov 12, 2014, at 2:53 PM, cyg Simple wrote:
>
>> On Wed, Nov 12, 2014 at 1:00 PM, Warren Young wrote:
>>>
>>> I think it would be an improvement to Cygwin if c:\cygwin contained only things that can be reinstalled from your local setup.exe download cache, in the same way that you can nuke "c:\Program Files\Microsoft Office $version” and reinstall without losing anything you created locally.
>>>
>>
>> What local changes/installations get lost?
>
> Currently, if you nuke a default installation into c:\cygwin, you lose /home, /etc, /var and /usr/local, all of which contain user files and/or local system configuration.
>

On Wed, Nov 12, 2014 at 5:21 PM, Andrey Repin wrote:
> Greetings, cyg Simple!
>
>> What local changes/installations get lost?
>
> What get lost, if you nuke Cygwin folder in default installation?
> Everything. Every single piece you could think about.
>

Cygwin cannot prevent stupidity.  These "nuked" files should be
recoverable by a restore process from a backup.  However, place your
files that setup doesn't control in other directories and use
/etc/fstab to map them.  For instance I have a c:/opt directory where
I install many applications.  I also have a c:/mnt directory where I
put things like c:/mnt/home and mount that to /home.  I can have two
different instance of Cygwin running with a common $HOME.

-- 
cyg 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: /usr/local, /var and */tmp in c:\Users\Public

[Andrey Repin]

Greetings, cyg Simple!

>> I didn’t want to derail the discussion about the future of /home with this,
>> so I’m starting a new thread.
>>
>> I think it would be an improvement to Cygwin if c:\cygwin contained only
>> things that can be reinstalled from your local setup.exe download cache, in
>> the same way that you can nuke "c:\Program Files\Microsoft Office $version”
>> and reinstall without losing anything you created locally.
>>

> What local changes/installations get lost?

What get lost, if you nuke Cygwin folder in default installation?
Everything. Every single piece you could think about.

>> Further design principles follow from this:
>>
>> - User data should live in directories that those users are normally allowed to write to.
>>
>> - Per-machine software and per-machine configuration should be in directories that local Administrators can normally write to.
>>
>> - Software built from source (/usr/local) should not be in c:\cygwin; it is per-machine configuration, and so should be elsewhere.
>>
>> - If you tighten down what remains so that normal users only get read permission, it should continue to function, in the same way that normal users on a Linux box don’t need write access to, say, /usr/include.
>>
>>
>> This /etc/fstab addition mostly accomplishes that:
>>
>>
>> c:/Users/Public/Cygwin/var         /var         ntfs   auto      0 0
>> c:/Users/Public/Cygwin/usr/local   /usr/local   ntfs   auto      0 0
>>
>> c:/Users/Public/Cygwin/tmp         /tmp         ntfs   notexec   0 0
>> c:/Users/Public/Cygwin/tmp         /usr/tmp     ntfs   notexec   0 0
>> c:/Users/Public/Cygwin/tmp         /var/tmp     ntfs   notexec   0 0
>>
>>
>> I propose that this or something like it be added to the default fstab.
>>

> Please NO not by default or offering an option.  A back end tool maybe
> in cygutils that can be run manually.

Give one good reason, other than impulsive screaming?


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 13.11.2014, <01:19>

Sorry for my terrible english...

Re: /usr/local, /var and */tmp in c:\Users\Public

[Corinna Vinschen]

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

On Nov 12 11:00, Warren Young wrote:
> I didn’t want to derail the discussion about the future of /home with
> this, so I’m starting a new thread.
> 
> I think it would be an improvement to Cygwin if c:\cygwin contained
> only things that can be reinstalled from your local setup.exe download
> cache, in the same way that you can nuke "c:\Program Files\Microsoft
> Office $version” and reinstall without losing anything you created
> locally.
> 
> Further design principles follow from this:
> 
> - User data should live in directories that those users are normally
> allowed to write to.
> 
> - Per-machine software and per-machine configuration should be in
> directories that local Administrators can normally write to.
> 
> - Software built from source (/usr/local) should not be in c:\cygwin;
> it is per-machine configuration, and so should be elsewhere.
> 
> - If you tighten down what remains so that normal users only get read
> permission, it should continue to function, in the same way that
> normal users on a Linux box don’t need write access to, say,
> /usr/include.
> 
> 
> This /etc/fstab addition mostly accomplishes that:
> 
> 
> c:/Users/Public/Cygwin/var         /var         ntfs   auto      0 0
> c:/Users/Public/Cygwin/usr/local   /usr/local   ntfs   auto      0 0
> 
> c:/Users/Public/Cygwin/tmp         /tmp         ntfs   notexec   0 0
> c:/Users/Public/Cygwin/tmp         /usr/tmp     ntfs   notexec   0 0
> c:/Users/Public/Cygwin/tmp         /var/tmp     ntfs   notexec   0 0
> 
> 
> I propose that this or something like it be added to the default
> fstab.

No.  This would even break Setup right now.  Also, Users\Public doesn't
exist on XP/2K3 so this needs additional logic as long as we support
XP/2K3.

I'm not entirely opposed to such an idea.  But...

- definitely not this year. or even the first half of next year.  We
  have to consolidate the changes to account handling first, and,
  right now, I'm basically the only developer working on the Cygwin
  core more than just doing small patches.

- A change like this should probably work in conjunction with a setting
  in the Setup GUI.

- So this requires changes in Setup and Cygwin.  I'm not going to do
  that, unless I have more support on the coding side, and more
  participation of serious coders on the cygwin-developer ML.

- Did I mention that stuff like this would be much less hassle if
  we had more people doing some coding?

> The only thing remaining in c:\cygwin that can’t be moved in this way
> — but which it would be nice to — is /etc.  If you try, you will find
> that it makes Cygwin asplode; cygwin1.dll needs to find
> $cygbindir/../etc in order to find /etc/fstab, at the least.

That's documented behaviour, and it's an obvious chicken/egg problem,
isn't it?  fstab is the file *defining* mount points, so Cygwin can't
use the mount points in fstab to find etc/fstab


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: /usr/local, /var and */tmp in c:\Users\Public

[Warren Young]

On Nov 13, 2014, at 2:55 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:

> On Nov 12 11:00, Warren Young wrote:
>> 
>> I propose that this or something like it be added to the default
>> fstab.
> 
> No.  This would even break Setup right now.

I’m guessing this is because setup.exe doesn’t know what to do with a redirected /var and /usr/local on the first install, when /etc/fstab doesn’t exist yet?

I assume setup.exe does obey /etc/fstab on subsequent installs.  If not, I can see that this will break the installation of any package that puts files in either location.

I don’t see that the */tmp changes would bother setup.exe.

None of these problems seem difficult.  Doesn’t setup.exe write the initial /etc/fstab, and so is in a position to know what it will contain on first install?
--
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: /usr/local, /var and */tmp in c:\Users\Public

[Corinna Vinschen]

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

On Nov 13 14:30, Warren Young wrote:
> On Nov 13, 2014, at 2:55 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > On Nov 12 11:00, Warren Young wrote:
> >> 
> >> I propose that this or something like it be added to the default
> >> fstab.
> > 
> > No.  This would even break Setup right now.
> 
> I’m guessing this is because setup.exe doesn’t know what to do with a
> redirected /var and /usr/local on the first install, when /etc/fstab
> doesn’t exist yet?
> 
> I assume setup.exe does obey /etc/fstab on subsequent installs.  If
> not, I can see that this will break the installation of any package
> that puts files in either location.
> 
> I don’t see that the */tmp changes would bother setup.exe.
> 
> None of these problems seem difficult.  Doesn’t setup.exe write the
> initial /etc/fstab, and so is in a position to know what it will
> contain on first install?

Perhaps, but I don't want to make such changes short-term, and I don't
want to enforce such a big change in directory layout.  This has to be
made configurable in the GUI.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: /usr/local, /var and */tmp in c:\Users\Public

[Andrey Repin]

Greetings, Warren Young!

>>> I propose that this or something like it be added to the default
>>> fstab.
>> 
>> No.  This would even break Setup right now.

> I’m guessing this is because setup.exe doesn’t know what to do with a
> redirected /var and /usr/local on the first install, when /etc/fstab doesn’t exist yet?

> I assume setup.exe does obey /etc/fstab on subsequent installs.  If not, I
> can see that this will break the installation of any package that puts files in either location.

I can't see, why it ever should care about /etc/fstab at all.
The postinstall scripts - they do, but again, they run in cygwin environment,
not native.

> I don’t see that the */tmp changes would bother setup.exe.

> None of these problems seem difficult.  Doesn’t setup.exe write the initial
> /etc/fstab, and so is in a position to know what it will contain on first install?

Even if it does, there's no reason to read it on subsequent updates.
The expectation is that the directory tree is in one place. If you really want
to scatter it, use native tools. It is possible and way less intrusive.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 14.11.2014, <01:34>

Sorry for my terrible english...