[VW] Accessing Windows ACL, making files writeable

Hi,

anybody know of an implementation for making a file or directory fully
accessible by all users (Windows, VisualWorks)? I have problems with
applications installed by Administrator and then run by an unprivileged
user. I want to set the appropriate rights of all files upon installation.

I never expected how $&%$&% complicated the Win32 API is wrt ACL access.
This is real horror.

Any suggestion is appreciated.

Andre

I solve these issues with the Windows Installer (.msi), so outside
visualworks. I build the installer in VisualStudio, and creating the
necessary infrastructure for VW to run I find is very straightforward.
Contact me if you want more details, which may be overkill in this
mailing list.

2007/4/19, Andre Schnoor <[hidden email]>:

Andre,

We solved this problem by using windows program called xcacls.exe.  That
is command line utility which comes with the XP PRo, or part of one of
their toolkits. It runs on NT4 sp6, Win2k, WinXP. Seem to run on vista
as well.

http://support.microsoft.com/kb/318754

If it is not part of window install you use, you can download it from M$
site.  after the install you would need to run it and tell what users
are allowed to do what.

I just looked at the XP home and XP pro  distro. disks --  there is a
program there CACLS.EXE which does the same thing, so you can reasonably
expect every xp system to have one, look  how to use it at:

http://support.microsoft.com/kb/135268/

You can use either one I think, my preference goes to the xcacls however
, I know it works almost everywhere...

Good Luck.

--Mark

Andre Schnoor wrote:

Thank you, Marc. That's a good direction to look further.

However, I'm afraid this won't work with localized versions of Windows,
e.g. in German the "Power Users" group is called "Hauptbenutzer". If I
didn't miss something, there's no way to use a generic user ID or such,
so I'm still in Redmond hell here.

I need to allow full access to all "Users" for several directories. This
doesn't seem to be possible without knowing the localized names for this
user group.

In fact, refering to well-known user groups by localized names reveals
how incredibly crappy this operating system actually is. Code examples
I've found that manipulate ACLs and ACEs require a hundred lines of code
even for the most primitive actions. I still can not believe it.

Thanks again,
Andre


Mark Pirogovsky wrote:
--
Andre Schnoor
Cognitone GmbH
www.cognitone.com

My condolences,

Don't grant specific users any rights, give them rights through group
affiliation. The groups are given access. Be careful, a restriction in a
Windows ACL will override a grant. Power users explicitly granted access
to something can be denied access because they are also members of a
'guest' group that is denied access. Define your own group. Leave it to
administrators to decide who belongs to a group. I recall Windows has
ways of identifying basic groups by a unique identifier rather than a
localized name. Changes to group ACL were not immediately
effective--unless you forced Windows to refresh.

I managed to get through that hell (without localization though) by
using the utilities already mentioned and driving them from VBScripts
(and batch files) that were able to retrieve information from Windows.
It was frustrating. You might avoid VBScript by wrapping Windows DLLs
and calling from within Smalltalk, but that wasn't an option for me
because the goal was to install a Smalltalk application in a locked-down
Windows NT Server environment. You've probably already discovered that
the Windows Registry has a different set of ACL issues to deal with.

If you want a script solution then it helps to recall how that stuff was
done in the 80's--DOS batch files, BASIC, and 3rd party utilities.

Paul Baumann


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Thursday, April 19, 2007 5:23 PM
To: Mark Pirogovsky
Cc: vwnc-list
Subject: Re: [VW] Accessing Windows ACL, making files writeable

Thank you, Marc. That's a good direction to look further.

However, I'm afraid this won't work with localized versions of Windows,
e.g. in German the "Power Users" group is called "Hauptbenutzer". If I
didn't miss something, there's no way to use a generic user ID or such,
so I'm still in Redmond hell here.

I need to allow full access to all "Users" for several directories. This
doesn't seem to be possible without knowing the localized names for this
user group.

In fact, refering to well-known user groups by localized names reveals
how incredibly crappy this operating system actually is. Code examples
I've found that manipulate ACLs and ACEs require a hundred lines of code
even for the most primitive actions. I still can not believe it.

Thanks again,
Andre


Mark Pirogovsky wrote:
--
Andre Schnoor
Cognitone GmbH
www.cognitone.com
 
 
 
--------------------------------------------------------
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.  
 

Andre,

You can find "Power Users" using the SID: S-1-5-32-547.
 
http://support.microsoft.com/kb/243330

Then the question is...Local or Domain? What a hassle.

Paul Baumann

-----Original Message-----
From: Paul Baumann [mailto:[hidden email]]
Sent: Friday, April 20, 2007 3:45 PM
To: [hidden email]; Mark Pirogovsky
Cc: vwnc-list
Subject: RE: [VW] Accessing Windows ACL, making files writeable

My condolences,

Don't grant specific users any rights, give them rights through group
affiliation. The groups are given access. Be careful, a restriction in a
Windows ACL will override a grant. Power users explicitly granted access
to something can be denied access because they are also members of a
'guest' group that is denied access. Define your own group. Leave it to
administrators to decide who belongs to a group. I recall Windows has
ways of identifying basic groups by a unique identifier rather than a
localized name. Changes to group ACL were not immediately
effective--unless you forced Windows to refresh.

I managed to get through that hell (without localization though) by
using the utilities already mentioned and driving them from VBScripts
(and batch files) that were able to retrieve information from Windows.
It was frustrating. You might avoid VBScript by wrapping Windows DLLs
and calling from within Smalltalk, but that wasn't an option for me
because the goal was to install a Smalltalk application in a locked-down
Windows NT Server environment. You've probably already discovered that
the Windows Registry has a different set of ACL issues to deal with.

If you want a script solution then it helps to recall how that stuff was
done in the 80's--DOS batch files, BASIC, and 3rd party utilities.

Paul Baumann


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Thursday, April 19, 2007 5:23 PM
To: Mark Pirogovsky
Cc: vwnc-list
Subject: Re: [VW] Accessing Windows ACL, making files writeable

Thank you, Marc. That's a good direction to look further.

However, I'm afraid this won't work with localized versions of Windows,
e.g. in German the "Power Users" group is called "Hauptbenutzer". If I
didn't miss something, there's no way to use a generic user ID or such,
so I'm still in Redmond hell here.

I need to allow full access to all "Users" for several directories. This
doesn't seem to be possible without knowing the localized names for this
user group.

In fact, refering to well-known user groups by localized names reveals
how incredibly crappy this operating system actually is. Code examples
I've found that manipulate ACLs and ACEs require a hundred lines of code
even for the most primitive actions. I still can not believe it.

Thanks again,
Andre


Mark Pirogovsky wrote:
--
Andre Schnoor
Cognitone GmbH
www.cognitone.com
 
 
 
--------------------------------------------------------
This message may contain confidential information and is intended for
specific recipients unless explicitly noted otherwise. If you have
reason to believe you are not an intended recipient of this message,
please delete it and notify the sender. This message may not represent
the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or
affiliates, and does not constitute a contract or guarantee. Unencrypted
electronic mail is not secure and the recipient of this message is
expected to provide safeguards from viruses and pursue alternate means
of communication where privacy or a binding message is desired.
 
 
 
--------------------------------------------------------
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.  
 

Thank you Paul,

I'll test the fixed SIDs with a code example I found here:

http://support.microsoft.com/kb/102102
http://support.microsoft.com/kb/157234

I still wonder why they didn't just imitate the Unix standards instead of reinventing the wheel in such a horribly overdone manner.

Andre


Paul Baumann wrote:

Andre,

You can find "Power Users" using the SID: S-1-5-32-547.
 
http://support.microsoft.com/kb/243330

Then the question is...Local or Domain? What a hassle.

Paul Baumann 

-----Original Message-----
From: Paul Baumann [[hidden email]] 
Sent: Friday, April 20, 2007 3:45 PM
To: [hidden email]; Mark Pirogovsky
Cc: vwnc-list
Subject: RE: [VW] Accessing Windows ACL, making files writeable

My condolences,

Don't grant specific users any rights, give them rights through group
affiliation. The groups are given access. Be careful, a restriction in a
Windows ACL will override a grant. Power users explicitly granted access
to something can be denied access because they are also members of a
'guest' group that is denied access. Define your own group. Leave it to
administrators to decide who belongs to a group. I recall Windows has
ways of identifying basic groups by a unique identifier rather than a
localized name. Changes to group ACL were not immediately
effective--unless you forced Windows to refresh.

I managed to get through that hell (without localization though) by
using the utilities already mentioned and driving them from VBScripts
(and batch files) that were able to retrieve information from Windows.
It was frustrating. You might avoid VBScript by wrapping Windows DLLs
and calling from within Smalltalk, but that wasn't an option for me
because the goal was to install a Smalltalk application in a locked-down
Windows NT Server environment. You've probably already discovered that
the Windows Registry has a different set of ACL issues to deal with.

If you want a script solution then it helps to recall how that stuff was
done in the 80's--DOS batch files, BASIC, and 3rd party utilities.

Paul Baumann 


-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Thursday, April 19, 2007 5:23 PM
To: Mark Pirogovsky
Cc: vwnc-list
Subject: Re: [VW] Accessing Windows ACL, making files writeable

Thank you, Marc. That's a good direction to look further.

However, I'm afraid this won't work with localized versions of Windows,
e.g. in German the "Power Users" group is called "Hauptbenutzer". If I
didn't miss something, there's no way to use a generic user ID or such,
so I'm still in Redmond hell here.

I need to allow full access to all "Users" for several directories. This
doesn't seem to be possible without knowing the localized names for this
user group.

In fact, refering to well-known user groups by localized names reveals
how incredibly crappy this operating system actually is. Code examples
I've found that manipulate ACLs and ACEs require a hundred lines of code
even for the most primitive actions. I still can not believe it.

Thanks again,
Andre


Mark Pirogovsky wrote:
  

Andre,

We solved this problem by using windows program called xcacls.exe.  
That is command line utility which comes with the XP PRo, or part of 
one of their toolkits. It runs on NT4 sp6, Win2k, WinXP. Seem to run 
on vista as well.

http://support.microsoft.com/kb/318754

If it is not part of window install you use, you can download it from 
M$ site.  after the install you would need to run it and tell what 
users are allowed to do what.

I just looked at the XP home and XP pro  distro. disks --  there is a 
program there CACLS.EXE which does the same thing, so you can 
reasonably expect every xp system to have one, look  how to use it at:

http://support.microsoft.com/kb/135268/

You can use either one I think, my preference goes to the xcacls 
however , I know it works almost everywhere...

Good Luck.

--Mark

Andre Schnoor wrote:
    

Hi,

anybody know of an implementation for making a file or directory 
fully accessible by all users (Windows, VisualWorks)? I have problems
      

with applications installed by Administrator and then run by an 
unprivileged user. I want to set the appropriate rights of all files 
upon installation.

I never expected how $&%$&% complicated the Win32 API is wrt ACL 
access. This is real horror.

Any suggestion is appreciated.

Andre



      

--
Andre Schnoor
Cognitone GmbH
www.cognitone.com 
  
  
  
--------------------------------------------------------
This message may contain confidential information and is intended for
specific recipients unless explicitly noted otherwise. If you have
reason to believe you are not an intended recipient of this message,
please delete it and notify the sender. This message may not represent
the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or
affiliates, and does not constitute a contract or guarantee. Unencrypted
electronic mail is not secure and the recipient of this message is
expected to provide safeguards from viruses and pursue alternate means
of communication where privacy or a binding message is desired. 
  
  
  
--------------------------------------------------------
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.  
 


  

-- 
Andre Schnoor
Cognitone GmbH
www.cognitone.com