vi stealing SYSTEM-owned permissions and ownership

vi stealing SYSTEM-owned permissions and ownership

[D. Boland]

Hi group,

I'm a Linux teacher at a school for vocational education in the Netherlands. 
I use Cyqwin to help my students overcome their fear of the command line by 
showing them their Windows systems through the eyes of Linux.

I had them install Apache and then configure it in Cygwin using vi.

As of Windows 8, the Apache installation sometimes fails, because of permission
issues. Installing "As administrator" solves the problem. This is fine 
with me because in other Linuxes, Apache is installed as root by default.

After installation, permissions in the Apache "conf" directory look like this:

drwx------+ 1 SYSTEM SYSTEM     0 28 okt 20:43 .
drwx------+ 1 SYSTEM SYSTEM     0  2 nov 13:10 ..
-rwx------+ 1 SYSTEM SYSTEM 35142 26 okt 18:07 httpd.conf
-rwx------+ 1 SYSTEM SYSTEM 34770  7 okt 23:29 httpd.default.conf
-rwx------+ 1 SYSTEM SYSTEM 13340  3 okt 07:59 magic
-rwx------+ 1 SYSTEM SYSTEM 13340 21 nov  2004 magic.default
-rwx------+ 1 SYSTEM SYSTEM 54599  3 okt 07:59 mime.types
-rwx------+ 1 SYSTEM SYSTEM 54599 17 mrt  2012 mime.types.default
-rwx------+ 1 SYSTEM SYSTEM  9390  5 feb  2013 openssl.cnf
-rwx------+ 1 SYSTEM SYSTEM 11050  3 okt 07:59 ssl.conf
-rwx------+ 1 SYSTEM SYSTEM 11030  7 okt 23:29 ssl.default.conf

To emulate the Unix permissions model, I had my students add a group in Windows,
named "apache", making themselves a member and then import it using the mkgroup 
command.

After a chgrp and chmod on the entire Apache folder, the "conf" directory looks 
like this:

drwxrwx---+ 1 SYSTEM apache     0 28 okt 20:43 .
drwxrwx---+ 1 SYSTEM apache     0  2 nov 13:10 ..
-rwxrwx---+ 1 SYSTEM apache 35142 26 okt 18:07 httpd.conf
-rwxrwx---+ 1 SYSTEM apache 34770  7 okt 23:29 httpd.default.conf
-rwxrwx---+ 1 SYSTEM apache 13340  3 okt 07:59 magic
-rwxrwx---+ 1 SYSTEM apache 13340 21 nov  2004 magic.default
-rwxrwx---+ 1 SYSTEM apache 54599  3 okt 07:59 mime.types
-rwxrwx---+ 1 SYSTEM apache 54599 17 mrt  2012 mime.types.default
-rwxrwx---+ 1 SYSTEM apache  9390  5 feb  2013 openssl.cnf
-rwxrwx---+ 1 SYSTEM apache 11050  3 okt 07:59 ssl.conf
-rwxrwx---+ 1 SYSTEM apache 11030  7 okt 23:29 ssl.default.conf

My students can now administer Apache without running Cygwin "As administrator".
Also, this is extremely useful in real-time business situations. It enables my 
students to grant Apache admin permissions to other users by putting them in 
the apache group, without giving them full admin access on the entire system.

But here's the problem. After editing the httpd.conf file with vi, the permissions 
on the "httpd.conf" file are changed to:

----------+ 1 Daniel None   35142  2 nov 13:20 httpd.conf

This should not be. I tested this on my RedHat and OpenBSD systems, and there are 
no changes in ownership or permissions after editing with vi.

After fiddling with chown, chgrp, chmod, getfacl, setfacl and icacl for a few 
hours, I finally installed nano. Nano behaved. It did not alter anything except
the contents of the file.

But I want my students to learn vi, so having them install nano is not an option. 

I think the problem is vi. Vi deletes the original file and creates a new one with
the changed contents, without resetting the original ownership and permissions. See 
also this post:

http://unix.stackexchange.com/questions/58880/how-does-vim-steal-root-owned-files

Can somebody shed some light on this?

Meanwhile, I accidentally found sort of a solution: deleting the file without write
permissions on the containing folder, restores the permissions set by Administrator.

As Administrator:
chmod 0700 .
touch test.txt
chown SYSTEM:apache test.txt
chmod 0770 test.txt

Results in:

-rwxrwx---+ 1 SYSTEM apache     0  2 nov 13:26 test.txt

As "normal" user:
Edit the file with vi. After, permissions will look like:

----------+ 1 Daniel None       9  2 nov 13:29 test.txt

$ getfacl.exe test.txt
# file: test.txt
# owner: Daniel
# group: None
user::---
group::---
group:SYSTEM:rwx
group:Administrators:rwx
group:Gebruikers:r-x
group:apache:rwx
mask:rwx
other:---

To "solve" this, simply delete the file:

rm test.txt

The file is not deleted because of 0700 on the containing folder. But the original 
permissions, set by Admin are restored!!

-rwxrwx---+ 1 SYSTEM apache     9  2 nov 13:29 test.txt

$ getfacl.exe test.txt
# file: test.txt
# owner: SYSTEM
# group: apache
user::rwx
group::rwx
group:Administrators:rwx
group:Gebruikers:r-x
mask:rwx
other:---


--
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: vi stealing SYSTEM-owned permissions and ownership

[Brian S. Wilson]

> I'm a Linux teacher at a school for vocational education in the
Netherlands. 
> I use Cyqwin to help my students overcome their fear of the command line
by showing them their Windows systems through the eyes of Linux.
...
> After a chgrp and chmod on the entire Apache folder, the "conf" directory
looks like this:
>
> drwxrwx---+ 1 SYSTEM apache     0 28 okt 20:43 .
> drwxrwx---+ 1 SYSTEM apache     0  2 nov 13:10 ..
> -rwxrwx---+ 1 SYSTEM apache 35142 26 okt 18:07 httpd.conf
> -rwxrwx---+ 1 SYSTEM apache 34770  7 okt 23:29 httpd.default.conf
> -rwxrwx---+ 1 SYSTEM apache 13340  3 okt 07:59 magic
> -rwxrwx---+ 1 SYSTEM apache 13340 21 nov  2004 magic.default
> -rwxrwx---+ 1 SYSTEM apache 54599  3 okt 07:59 mime.types
> -rwxrwx---+ 1 SYSTEM apache 54599 17 mrt  2012 mime.types.default
> -rwxrwx---+ 1 SYSTEM apache  9390  5 feb  2013 openssl.cnf
> -rwxrwx---+ 1 SYSTEM apache 11050  3 okt 07:59 ssl.conf
> -rwxrwx---+ 1 SYSTEM apache 11030  7 okt 23:29 ssl.default.conf
> 
>My students can now administer Apache without running Cygwin "As
administrator".

Your statement may not be quite accurate.  The Cygwin Apache instance
appears to be running as the "SYSTEM" user since that is the file owner, but
your students can administer the files because they are members of the
"apache" group.  I can't really tell which user id is running your Apache
process because I don't know how you are actually starting the Apache
process.  Most production Apache instances do not run as the "root" user
since this is a security risk.

If my guess about the Apache process owner is correct, please make your
students aware that if someone hacks their Cygwin Apache servers, the hacker
may gain the same user access rights as the user id actually running the
Apache process.  The Apache process owner would normally be a unique user
account with no login or access privileges to protect the server from
successful attacks (just because your Apache files are owned by "SYSTEM",
Apache could be started under another, less privileged, user id for better
protection; but it is common practice to have the file owner also be the
user id that normally executes the file).  It is common to see a "nobody"
user as the owner of Apache in production systems.

I've spent some time over several years trying to figure out how to get
Apache working as a "nobody" user under Cygwin.  I've never succeeded in
getting it to work properly, and my comments to this board have not yielded
an answered.  I don't think it is possible to make Apache work this way
under Cygwin, but your students should be made aware of this difference.

If anyone is aware of how to get Apache working using a restricted "nobody"
user id under Cygwin, please respond (or start a new thread).


--
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: vi stealing SYSTEM-owned permissions and ownership

[Andrey Repin]

Greetings, Brian S. Wilson!

>> I'm a Linux teacher at a school for vocational education in the Netherlands.
>> I use Cyqwin to help my students overcome their fear of the command line by
>> showing them their Windows systems through the eyes of Linux.
> ...
>> After a chgrp and chmod on the entire Apache folder, the "conf" directory
>> looks like this: 
>>
>> drwxrwx---+ 1 SYSTEM apache     0 28 okt 20:43 .
>> drwxrwx---+ 1 SYSTEM apache     0  2 nov 13:10 ..
>> -rwxrwx---+ 1 SYSTEM apache 35142 26 okt 18:07 httpd.conf
>> -rwxrwx---+ 1 SYSTEM apache 34770  7 okt 23:29 httpd.default.conf
>> -rwxrwx---+ 1 SYSTEM apache 13340  3 okt 07:59 magic
>> -rwxrwx---+ 1 SYSTEM apache 13340 21 nov  2004 magic.default
>> -rwxrwx---+ 1 SYSTEM apache 54599  3 okt 07:59 mime.types
>> -rwxrwx---+ 1 SYSTEM apache 54599 17 mrt  2012 mime.types.default
>> -rwxrwx---+ 1 SYSTEM apache  9390  5 feb  2013 openssl.cnf
>> -rwxrwx---+ 1 SYSTEM apache 11050  3 okt 07:59 ssl.conf
>> -rwxrwx---+ 1 SYSTEM apache 11030  7 okt 23:29 ssl.default.conf
>> 
>>My students can now administer Apache without running Cygwin "As
> administrator".

> Your statement may not be quite accurate.  The Cygwin Apache instance
> appears to be running as the "SYSTEM" user since that is the file owner, but
> your students can administer the files because they are members of the
> "apache" group.  I can't really tell which user id is running your Apache
> process because I don't know how you are actually starting the Apache
> process.  Most production Apache instances do not run as the "root" user
> since this is a security risk.

> If my guess about the Apache process owner is correct, please make your
> students aware that if someone hacks their Cygwin Apache servers, the hacker
> may gain the same user access rights as the user id actually running the
> Apache process.  The Apache process owner would normally be a unique user
> account with no login or access privileges to protect the server from
> successful attacks (just because your Apache files are owned by "SYSTEM",
> Apache could be started under another, less privileged, user id for better
> protection; but it is common practice to have the file owner also be the
> user id that normally executes the file).  It is common to see a "nobody"
> user as the owner of Apache in production systems.

> I've spent some time over several years trying to figure out how to get
> Apache working as a "nobody" user under Cygwin.  I've never succeeded in
> getting it to work properly, and my comments to this board have not yielded
> an answered.  I don't think it is possible to make Apache work this way
> under Cygwin, but your students should be made aware of this difference.

> If anyone is aware of how to get Apache working using a restricted "nobody"
> user id under Cygwin, please respond (or start a new thread).

I can't imagine alot of reasons to not use native Windows Apache server, which
is much better adapted for running in Windows security environment.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 02.11.2013, <21:44>

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: vi stealing SYSTEM-owned permissions and ownership

[D. Boland]

"Brian S. Wilson" wrote:
> 
> > I'm a Linux teacher at a school for vocational education in the
> Netherlands.
> > I use Cyqwin to help my students overcome their fear of the command line
> by showing them their Windows systems through the eyes of Linux.
> ...
> > After a chgrp and chmod on the entire Apache folder, the "conf" directory
> looks like this:
> >
> > drwxrwx---+ 1 SYSTEM apache     0 28 okt 20:43 .
> > drwxrwx---+ 1 SYSTEM apache     0  2 nov 13:10 ..
> > -rwxrwx---+ 1 SYSTEM apache 35142 26 okt 18:07 httpd.conf
> > -rwxrwx---+ 1 SYSTEM apache 34770  7 okt 23:29 httpd.default.conf
> > -rwxrwx---+ 1 SYSTEM apache 13340  3 okt 07:59 magic
> > -rwxrwx---+ 1 SYSTEM apache 13340 21 nov  2004 magic.default
> > -rwxrwx---+ 1 SYSTEM apache 54599  3 okt 07:59 mime.types
> > -rwxrwx---+ 1 SYSTEM apache 54599 17 mrt  2012 mime.types.default
> > -rwxrwx---+ 1 SYSTEM apache  9390  5 feb  2013 openssl.cnf
> > -rwxrwx---+ 1 SYSTEM apache 11050  3 okt 07:59 ssl.conf
> > -rwxrwx---+ 1 SYSTEM apache 11030  7 okt 23:29 ssl.default.conf
> >
> >My students can now administer Apache without running Cygwin "As
> administrator".
> 
> Your statement may not be quite accurate.  The Cygwin Apache instance
> appears to be running as the "SYSTEM" user since that is the file owner, but
> your students can administer the files because they are members of the
> "apache" group.  I can't really tell which user id is running your Apache
> process because I don't know how you are actually starting the Apache
> process.  Most production Apache instances do not run as the "root" user
> since this is a security risk.
> 
> If my guess about the Apache process owner is correct, please make your
> students aware that if someone hacks their Cygwin Apache servers, the hacker
> may gain the same user access rights as the user id actually running the
> Apache process.  The Apache process owner would normally be a unique user
> account with no login or access privileges to protect the server from
> successful attacks (just because your Apache files are owned by "SYSTEM",
> Apache could be started under another, less privileged, user id for better
> protection; but it is common practice to have the file owner also be the
> user id that normally executes the file).  It is common to see a "nobody"
> user as the owner of Apache in production systems.
> 
> I've spent some time over several years trying to figure out how to get
> Apache working as a "nobody" user under Cygwin.  I've never succeeded in
> getting it to work properly, and my comments to this board have not yielded
> an answered.  I don't think it is possible to make Apache work this way
> under Cygwin, but your students should be made aware of this difference.
> 
> If anyone is aware of how to get Apache working using a restricted "nobody"
> user id under Cygwin, please respond (or start a new thread).

Your concern is very real, I thought about that also.

First, in my student-setup, Apache is not running under Cygwin. I used the 
.msi distribution, available on the Apache website. This installs Apache as a 
native Windows Service, and it can be configured using the Windows Services 
Control Panel.

As to running as the SYSTEM user, I agree with you. In Linux, Apache is started
by root, and then immediately switches to the "nobody" user, so it is unable 
to touch or even see the outside of its ServerRoot.

In Windows, this mechanism does not work. That is why the "User" and "Group"
directives are left out of the httpd.conf file in the Windows distribution.

I now have Apache running under the username "Daemon" which I created using 
the standard Windows "Users" Control Panel. I put this user in my "apache" 
group like this:

net localgroup apache Daemon /add

The tricky part was assigning the following permissions to the "Daemon"
user:

* Log on as a service
* Act as part of the operating system

I did this in the "Local Security Settings" Control Panel, which can 
be found in the "System Administration" Control Panel. It is also possible to 
bring it up by running "secpol.msc" from the Start menu.

Finally, I configured Apache to run as user "Daemon" in the "Services" control 
panel (services.msc).

Daniel


--
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: vi stealing SYSTEM-owned permissions and ownership

[Andrey Repin]

Greetings, D. Boland!

> First, in my student-setup, Apache is not running under Cygwin. I used the
> .msi distribution, available on the Apache website. This installs Apache as a 
> native Windows Service, and it can be configured using the Windows Services 
> Control Panel.

> As to running as the SYSTEM user, I agree with you. In Linux, Apache is started
> by root, and then immediately switches to the "nobody" user, so it is unable 
> to touch or even see the outside of its ServerRoot.

> In Windows, this mechanism does not work. That is why the "User" and "Group"
> directives are left out of the httpd.conf file in the Windows distribution.

> I now have Apache running under the username "Daemon" which I created using 
> the standard Windows "Users" Control Panel. I put this user in my "apache" 
> group like this:

> net localgroup apache Daemon /add

> The tricky part was assigning the following permissions to the "Daemon"
> user:

> * Log on as a service
> * Act as part of the operating system

> I did this in the "Local Security Settings" Control Panel, which can 
> be found in the "System Administration" Control Panel. It is also possible to 
> bring it up by running "secpol.msc" from the Start menu.

> Finally, I configured Apache to run as user "Daemon" in the "Services" control 
> panel (services.msc).

Your main problem is that you are trying to break into native Windows
ACL system with Cygwin tools. And not only that, you also trying to
wrest native ACLs into POSIX permissions, and expect native applications to
work fine afterward.
Which can be done theoretically, but in reality is a real big headache to
maintain.

If you truly want to show your students their Windows systems from the command
line, I suggest you learn Windows command line.
If not very robust, it is nonetheless rich, and allow for many operations
normally performed from GUI, and some operations, that can not be done from
GUI, either without much complication or at all.
In the case mentioned below, the "net" tool should come in handy. As well
as "sc" tool.

Or, if you really want to use Cygwin tools to work along with Windows tools,
use noacl mount option and let Windows care about control rights and stuff.

Bottom line is: Either stick to Cygwin and leave Windows alone, or play by
Windows rules.

Also, forcing someone to use vi over more sane editors is a torture which no
one deserve.


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

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: vi stealing SYSTEM-owned permissions and ownership

[D. Boland]

Andrey Repin wrote:
> 
> Greetings, D. Boland!
> 
> Your main problem is that you are trying to break into native Windows
> ACL system with Cygwin tools. And not only that, you also trying to
> wrest native ACLs into POSIX permissions, and expect native applications to
> work fine afterward.
> Which can be done theoretically, but in reality is a real big headache to
> maintain.

You are speaking of Cygwin as if it's some kind of quick hack. This is not the case.
Most of the tools are of the GNU software collection, which is high quality
software. ACL is also available on other Linux flavours, and they don't have to
"wrest" it into POSIX.

Also, one could say that ACL is a superset of the POSIX model. It uses POSIX's idea
of users, groups and others, but then offers the posibility to add more users and
groups for more elaborate schemes. The headache starts when one actually starts
using these extra posibilities.

> 
> If you truly want to show your students their Windows systems from the command
> line, I suggest you learn Windows command line.
> If not very robust, it is nonetheless rich, and allow for many operations
> normally performed from GUI, and some operations, that can not be done from
> GUI, either without much complication or at all.
> In the case mentioned below, the "net" tool should come in handy. As well
> as "sc" tool.
> 

I could just give my students an iMac, but these are not used in IT production
infrastructures. Windows (business/government) and Linux/Unix (ISP's) are.

The Windows command line is frustrating to work on. For instance, their
implementation of autocompleting with the tab-key sucks. In stead of really
simplifying and improving on DOS, MS comes up with more weird tools like PowerShell.
Now you have to be a programmer to use the command-line.

> Also, forcing someone to use vi over more sane editors is a torture which no
> one deserve.
> 

Haha, yes. But if my students have to administer remote production-machines, most of
the time they have no other option. I want them to succeed where others fail.

> Sorry for my terrible english...

No problem.

Sincerely,
Daniel


--
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: vi stealing SYSTEM-owned permissions and ownership

[Andrey Repin]

Greetings, D. Boland!

>> Your main problem is that you are trying to break into native Windows
>> ACL system with Cygwin tools. And not only that, you also trying to
>> wrest native ACLs into POSIX permissions, and expect native applications to
>> work fine afterward.
>> Which can be done theoretically, but in reality is a real big headache to
>> maintain.

> You are speaking of Cygwin as if it's some kind of quick hack.

It is NOT a "quick hack". But to work across different paradigm boundaries,
you have to know, what exactly it means and how it works.

> This is not the case. Most of the tools are of the GNU software collection,
> which is high quality software. ACL is also available on other Linux
> flavours, and they don't have to "wrest" it into POSIX.

I'm NOT talking about tools provided. I tell you about inherent difference
between POSIX and Windows ACL's, short version and consequences of which I've
explained already, and you can find some more technical details in Cygwin
documentation. 

> Also, one could say that ACL is a superset of the POSIX model.

No, unfortunately, you can not. As I said, there's inherent differences.

> It uses POSIX's idea of users, groups and others, but then offers the
> posibility to add more users and groups for more elaborate schemes. The
> headache starts when one actually starts using these extra posibilities.

POSIX ACL do not use selective inheritance model, as I'm aware.

>> If you truly want to show your students their Windows systems from the command
>> line, I suggest you learn Windows command line.
>> If not very robust, it is nonetheless rich, and allow for many operations
>> normally performed from GUI, and some operations, that can not be done from
>> GUI, either without much complication or at all.
>> In the case mentioned below, the "net" tool should come in handy. As well
>> as "sc" tool.

> I could just give my students an iMac, but these are not used in IT production
> infrastructures. Windows (business/government) and Linux/Unix (ISP's) are.

You make it sound like Macs are something from a parallel universe.
Same *NIX, just more thoroughly put together. For the record: I've had a
MacBook for near a year. Wrested it all to my needs. No problem whatsoever.

> The Windows command line is frustrating to work on. For instance, their
> implementation of autocompleting with the tab-key sucks.

I'll give you a hint: http://farmanager.com/index.php?l=en

> In stead of really simplifying and improving on DOS, MS comes up with more
> weird tools like PowerShell.
> Now you have to be a programmer to use the command-line.

No need to "use command line". This is where you make a mistake. You use
command-line tools to perform specific tasks. That's it.
But if you inclined to "use command line", check out http://jpsoft.com/all-downloads/downloads.html

>> Also, forcing someone to use vi over more sane editors is a torture which no
>> one deserve.
>> 

> Haha, yes. But if my students have to administer remote production-machines,
> most of the time they have no other option. I want them to succeed where
> others fail. 

I can't imagine a situation, where I only have one way to edit the file.
Even on my web hosting, I have a choice between vi, mcedit, ed and ee.


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

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: vi stealing SYSTEM-owned permissions and ownership

[Brian S. Wilson]

> Haha, yes. But if my students have to administer remote
production-machines, most of the time they have no other option. I want them
to succeed where others fail.
If this is the case, why not use the Apache instance available through
Cygwin itself instead of implementing this Windows/Cygwin hybrid
environment?  Your students would get a better feel for a Posix
implementation of Apache, and a standard set up if the environment were
consistent.
Please contact me if you have any questions or concerns.
Sincerely,
Brian S. Wilson


--
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: vi stealing SYSTEM-owned permissions and ownership

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> > Haha, yes. But if my students have to administer remote
> production-machines, most of the time they have no other option. I want them
> to succeed where others fail.

Reading this thread, it looks like it digressed far away from the original point
($subject) as to why "vi" did not keep the original owner of an edited file.
(also pointed out was that "nano" did)...  A reasonable expectation, IMO.

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
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: vi stealing SYSTEM-owned permissions and ownership

[Larry Hall (Cygwin)]

On 11/4/2013 9:50 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>>> Haha, yes. But if my students have to administer remote
>> production-machines, most of the time they have no other option. I want them
>> to succeed where others fail.
>
> Reading this thread, it looks like it digressed far away from the original point
> ($subject) as to why "vi" did not keep the original owner of an edited file.
> (also pointed out was that "nano" did)...  A reasonable expectation, IMO.

I noted the same thing (to myself).  When I looked at the information
provided, I was left with the distinct impression that the 'vi' in use
was not a Cygwin version.  The fact that the file edited with it had no
POSIX permissions was a red flag for me.  I was going to suggest checking
this but as the conversation had already drifted into other areas, it
seemed of small concern to the larger issues being discussed.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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: vi stealing SYSTEM-owned permissions and ownership

[D. Boland]

Thanks for the input, guys.

I think I have new information on the stealing of ownership. Below test has been
performed on the Apache folder, placed in the Windows Program Files folder by the
Apache msi installer:

"/cygdrive/c/Program Files (x86)/Apache Group/Apache2/"

But if I perform the same test in my Cygwin home directory, vi behaves beautifully.

So, I was thinking this difference must be related to the Windows ACL assigments on
the "Program Files" folder.
Maybe vi is confused within this folder, because it is a system folder which
recursively forces extra permissions on its subfolders.

This means I could solve the issue by telling the Apache installer to put the files
in a "neutral" folder, like:

/cygdrive/c/apache/

But then the question would stay, nagging in my mind: why would vi be confused and
nano (and notepad.exe by the way) not? 

Also, Larry Hall pointed out:

"When I looked at the information provided, I was left with the distinct impression
that the 'vi' in use was not a Cygwin version.  The fact that the file edited with
it had no POSIX permissions was a red flag for me."

I initially used the original version of "vi" that came with the standard distro of
Cygwin. When I noticed the problem, I installed "vim" and went on, testing with
that.

I really, really would like to persue this issue some more in the direction Larry
points to.

Cincerely,
Daniel


"D. Boland" wrote:
> 
> Meanwhile, I accidentally found sort of a solution: deleting the file without write
> permissions on the containing folder, restores the permissions set by Administrator.
> 
> As Administrator:
> chmod 0700 .
> touch test.txt
> chown SYSTEM:apache test.txt
> chmod 0770 test.txt
> 
> Results in:
> 
> -rwxrwx---+ 1 SYSTEM apache     0  2 nov 13:26 test.txt
> 
> As "normal" user:
> Edit the file with vi. After, permissions will look like:
> 
> ----------+ 1 Daniel None       9  2 nov 13:29 test.txt
> 
> $ getfacl.exe test.txt
> # file: test.txt
> # owner: Daniel
> # group: None
> user::---
> group::---
> group:SYSTEM:rwx
> group:Administrators:rwx
> group:Gebruikers:r-x
> group:apache:rwx
> mask:rwx
> other:---
> 
> To "solve" this, simply delete the file:
> 
> rm test.txt
> 
> The file is not deleted because of 0700 on the containing folder. But the original
> permissions, set by Admin are restored!!
> 
> -rwxrwx---+ 1 SYSTEM apache     9  2 nov 13:29 test.txt
> 
> $ getfacl.exe test.txt
> # file: test.txt
> # owner: SYSTEM
> # group: apache
> user::rwx
> group::rwx
> group:Administrators:rwx
> group:Gebruikers:r-x
> mask:rwx
> other:---


--
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: vi stealing SYSTEM-owned permissions and ownership

[Achim Gratz]

D. Boland writes:
> I think I have new information on the stealing of ownership. Below test has been
> performed on the Apache folder, placed in the Windows Program Files folder by the
> Apache msi installer:
>
> "/cygdrive/c/Program Files (x86)/Apache Group/Apache2/"
>
> But if I perform the same test in my Cygwin home directory, vi behaves beautifully.
>
> So, I was thinking this difference must be related to the Windows ACL assigments on
> the "Program Files" folder.

If you are operating as a normal user on this folder, you aren't
actually editing the files you think you see there, the whole contents
is virtualized by UAC and redirected to your own personal copy on edit.
If you want to keep your sanity, do not place anything that you intend
to edit / change as a normal user into system directories on Win7 (that
includes Cygwin itself).

http://msdn.microsoft.com/en-us/library/bb756960.aspx


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra


--
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: vi stealing SYSTEM-owned permissions and ownership

[D. Boland]

Achim Gratz wrote:
> 
> D. Boland writes:
> > I think I have new information on the stealing of ownership. Below test has been
> > performed on the Apache folder, placed in the Windows Program Files folder by the
> > Apache msi installer:
> >
> > "/cygdrive/c/Program Files (x86)/Apache Group/Apache2/"
> >
> > But if I perform the same test in my Cygwin home directory, vi behaves beautifully.
> >
> > So, I was thinking this difference must be related to the Windows ACL assigments on
> > the "Program Files" folder.
> 
> If you are operating as a normal user on this folder, you aren't
> actually editing the files you think you see there, the whole contents
> is virtualized by UAC and redirected to your own personal copy on edit.
> If you want to keep your sanity, do not place anything that you intend
> to edit / change as a normal user into system directories on Win7 (that
> includes Cygwin itself).
> 
> http://msdn.microsoft.com/en-us/library/bb756960.aspx
> 
> Regards,
> Achim.

Thanks for this input. So Apache should be put in a folder, outside the windows
special folders, like:

/cygdrive/c/Apache2

This seems to be the default for most open source distributions: cygwin, perl, msys,
mingw, even xampp. I am still wondering, though, why the Apache Foundation wants it
in the "Program Files" folder.

You all are right in saying that the Apache .msi is a "hybrid" configuration. I
guess, maybe it's better to just use the Apache installation provided by CygWin...

I also found out about "cygrunsrv". This makes Linux daemons run Windows-native.
Very nice.

Thanks again for your input,
Daniel


--
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: vi stealing SYSTEM-owned permissions and ownership

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> > If you are operating as a normal user on this folder, you aren't
> > actually editing the files you think you see there, the whole contents
> > is virtualized by UAC and redirected to your own personal copy on edit.

While it does sound feasible, it does not explain the fact that
the other editors used by the OP, have not changed the file ownership
on editing the file contents..

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
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: vi stealing SYSTEM-owned permissions and ownership

[Andrey Repin]

Greetings, D. Boland!

>> > I think I have new information on the stealing of ownership. Below test has been
>> > performed on the Apache folder, placed in the Windows Program Files folder by the
>> > Apache msi installer:
>> >
>> > "/cygdrive/c/Program Files (x86)/Apache Group/Apache2/"
>> >
>> > But if I perform the same test in my Cygwin home directory, vi behaves beautifully.
>> >
>> > So, I was thinking this difference must be related to the Windows ACL assigments on
>> > the "Program Files" folder.
>> 
>> If you are operating as a normal user on this folder, you aren't
>> actually editing the files you think you see there, the whole contents
>> is virtualized by UAC and redirected to your own personal copy on edit.
>> If you want to keep your sanity, do not place anything that you intend
>> to edit / change as a normal user into system directories on Win7 (that
>> includes Cygwin itself).
>> 
>> http://msdn.microsoft.com/en-us/library/bb756960.aspx
>> 
>> Regards,
>> Achim.

> Thanks for this input. So Apache should be put in a folder, outside the windows

Erm, should be? Why? What made you think so?

> special folders, like:

> /cygdrive/c/Apache2

> This seems to be the default for most open source distributions: cygwin, perl, msys,
> mingw, even xampp.

XAMPP is a software collection, much like MSYS or Cygwin. It's easier to
maintain cross-application dependencies, where no other factors involved, but
I do not see, why XAMPP or MSYS would not live (relatively) peacefully inside
the %ProgramFiles% - they are both native Windows projects.
Cygwin is a bit specific, as it is aimed to cross the bridge between two
worlds. But the only real restriction so far was that it should not be
installed into a path with space anywhere in it's name. That's why C:/Cygwin
is a default location for it.
Perl (the distributions I've seen myself, other than Cygwin), live perfectly
fine in the %ProgramFiles%, so does MySQL, as well as it's tools, s.a. damned
WorkBench. 

> I am still wondering, though, why the Apache Foundation wants it
> in the "Program Files" folder.

Because they know what they are doing. And expect users to know, too.
%ProgramFiles% is a standard place for software installation in Windows.
And Apache httpd just play by the rules of the system.
Also, each Apache binary contain a manifest.

> You all are right in saying that the Apache .msi is a "hybrid" configuration.

It isn't. Or I do not understand the meaning of "hybrid" in this case.

> I guess, maybe it's better to just use the Apache installation provided by CygWin...

Depends, what you want to achieve.

> I also found out about "cygrunsrv". This makes Linux daemons run Windows-native.
> Very nice.

Not quite... As has been said already, there's implied limitations and
caveats, in many places. Just take the every-so-often reappearing topic of
setting up SSH server with Cygwin.

P.S.
Run this command from elevated shell:
reg ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /f /v "EnableVirtualization" /t REG_DWORD /d 0

That will deal with this stuff once and for all. Assuming you move the
"%LocalAppData%\VirtualStore" folders out of the way.
Once you reboot the system with this flag set, you will see "Access denied"
or "write failed", where they happen, no longer concealed by operating system
trying to outsmart the user.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 08.11.2013, <23:32>

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: vi stealing SYSTEM-owned permissions and ownership

[D. Boland]

Again, thanks for the input. I's now about three weeks later. I made all of my
students re-install Apache in:

/cygdrive/c/Apache2

and made them symlink this location on:

/usr/local/apache

For me, Achim Gratz's comment on the "Program Files" folder made perfect sense:

>If you are operating as a normal user on this folder, you aren't
>actually editing the files you think you see there, the whole contents
>is virtualized by UAC and redirected to your own personal copy on edit.
>If you want to keep your sanity, do not place anything that you intend
>to edit / change as a normal user into system directories on Win7 (that
>includes Cygwin itself).

I am also a software developer, and most of my releases are installed on MS Citrix
servers for remote desktop connections. I initially made the mistake to put all
files in the "Programs Files" folder, including the executable, the database and
configuration files (.ini).

This works fine on a stand-alone XP/Win7 PC, but in a Citrix environment this
crashes the application, because of lacking write permissions on the .ini files.
Then I found out about the "Application Data" folder. Releasing my database and .ini
files to that folder solved the problem. MS has an article about it:

http://msdn.microsoft.com/en-us/library/windows/apps/jj553522.aspx

This would mean that in order to install Windows native and avoid virtualization of
the conf files the Apache Group should release Apache for Windows into both "Program
Files" and "Application Data":

Program Files
-------------
bin
error
icons
include
lib
manual
modules

Application Data
----------------
cgi-bin
conf
htdocs
logs
proxy

Thanks again for the comments,
Daniel

-- 
Sent by my Altair 8800


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