COMMON_DOCUMENTS - What did I get wrong on these?

[NewsArchive]

Hello all,

my perception of storing data to COMMON_DOCUMENTS was until now, that ALL
users, and I mean ALL, either Admins or Normalos, can run a program that
reads and _writes_ data stored in C:\Documents and Settings\All
Users\Documents.

But I was proofed wrong!

I built an install that does perfectly puts my TPS into this
COMMON_DOCUMENTS.

Unfortunately I cannot run this install as a standard user, it requires
admin permissions when using XP.

Under Vista (business) a standard user can run this install without any
problem.

When called as admin (under XP) it installs the EXE into C:\program
files\myProject.

I have expected now that if any user calls this EXE he/she/it would have
READWRITE permissions on the data files.

But its not that way under XP, other than the often scolded Vista - now I
wonder why - what did I get wrong over the time?


Thank you for any input
Wolfgang






--
Grüße / Regards
Wolfgang Orth

http://www.odata.de



Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[NewsArchive]

Hi Wolfgang,

> Unfortunately I cannot run this install as a standard user, it requires
> admin permissions when using XP.

Then you, or something, have changed security permissions to this folder
under XP. I use COMMON_DOCUMENTS in various installs and never had problems
with it on XP or vista. For the past month I have been doing almost daily
tests on both XP and Vista with a program that uses subfolder in
COMMON_DOCUMENTS. Never seen issue with it.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

I'd guess your XP users are either Administrators (which most home users
are) or Power Users.

Test your app on a clean XP machine with more than one ordinary user account
(see my post to Wolfgang about the creator owner catch).

Jane

[NewsArchive]

> Hi Wolfgang,
>
> On 18 Dec 2008 17:04:04 -0500, Wolfgang Orth wrote:
>
>> Unfortunately I cannot run this install as a standard user, it requires
>> admin permissions when using XP.
>
> Then you, or something, have changed security permissions to this folder
> under XP.


no, definately not! I tested this on several machines, even a fresh
installed XP

When I right-click on a TPS I see that it is not write-protected.

The folder ha no write-protect when I look ate ht eproperties while I am
Admin, but when I am a User the mark for write-protection is checked.
Which does not matter because I can run my EXE as Admin, and all is
well..... no its NOT! <grmmml>


> I use COMMON_DOCUMENTS in various installs and never had problems with
> it on XP or vista.

On Vista ist okay, but the EXE has no manifest right now <sigh>


thx any and see you later, Arnor


bye
Wolfgang



--
Grüße / Regards
Wolfgang Orth

http://www.odata.de



Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[NewsArchive]

Yes.
And no.

All users *can* write within COMMON_DOCUMENTS, but on XP there's a catch (as
I described in a clarionmag article:
http://www.clarionmag.com/cmag/v9/v9n08vista4.html) -

Permissions are set so that "creator owner" has full control of a document.
This means that Betty can create a document and save it in COMMON_DOCUMENTS.
Bill can read Betty's document, but can't modify it unless he's a power user
or an administrator.
If Joe runs your app and it creates TPS files in that folder, other
"regular" XP users won't be able to modify it.

See attached excerpt from Microsoft's Vista Resource Kit. Ordinary users
have Write permission to the FOLDER, but not to files within it. So they
can create a file (which makes them the creator owner for that file), but
cannot modify other peoples' files.

Jane

[NewsArchive]

Hi Jane,

> See attached excerpt from Microsoft's Vista Resource Kit. Ordinary users
> have Write permission to the FOLDER, but not to files within it. So they
> can create a file (which makes them the creator owner for that file), but
> cannot modify other peoples' files.

Since XP's users are admins by default I'm not sure this is a (big) issue
for most home users.

The article you pointed to talks only about vista and I don't think this is
an issue under Vista. At least my test with admin and regular user accounts
seem to work fine under vista using subfolders in CSIDL_COMMON_DOCUMENTS.

But... What is a program to do? What can be done if you hit a computer
with XP where the user is not admin/power user and does not have write
permission?

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

XP users may be admins by default on a home machine. But I guarantee you
that XP users in an Active Directory domain in a business environment are
NOT admins by default <g>.

As for "what's a program to do"... a major purpose of my driving to LA in
early 2007 for a Vista rollout for developers MS thing was to ask that very
question. The idiot woman said "you can look that up on MSDN". Yeah,
right.

What you COULD do is have your elevated installer create your own data
folder within COMMON_DOCUMENTS.
Then use SB's Set Access Control script item to give EVERYONE full control
to that folder.
Attached is a script that I ran on an XP machine. Attached screen shot
shows that it did create a folder and give Everyone Full Control.
To test it, I created x.txt using my account. Then logged on as a different
ordinary user and was able to modify it successfully.

Jane

[NewsArchive]

Hi Jane,

> What you COULD do is have your elevated installer create your own data
> folder within COMMON_DOCUMENTS.
> Then use SB's Set Access Control script item to give EVERYONE full control
> to that folder.
> Attached is a script that I ran on an XP machine. Attached screen shot
> shows that it did create a folder and give Everyone Full Control.
> To test it, I created x.txt using my account. Then logged on as a different
> ordinary user and was able to modify it successfully.

Thank you very much for the script. But...<g> If we need to set the
permission on the subfolder for XP (I presume this is XP only since I have
not had problems with this with vista testing), then it seems to me that we
are back to COMMON_APPDATA looking promising. You just need to set the
read/write access for everyone there under vista (and perhaps XP too?)

It looks to me that this is now starting to point more to using that folder
rather than COMMON_DOCUMENTS, and just set the permission to it for
everyone. I'm talking about just general datafile (read .TPS files etc)

HMMMMM....!

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Yes, on Vista there are different permissions and COMMON_DOCUMENTS works.
As Wolfgang reported - his problem was only with XP users.

Yes, the excerpt I posted previously addressed XP - which was his issue.
The attached excerpt from the Vista RK addresses this kind of data sharing
on a Vista machine.

Jane

[NewsArchive]

Jane,

> Yes.
> And no.

BOOM!

Thanks for your insight, thanks a real lot! You saved me from drifting
into insanity....

I have had read your article way back then, but under an other aspect and
this topic finally slipped away.

My experience so far with Vista is (only a few late night tests) that it
works quite well. Its XP that is so cumbersome.

As I have no clue where and on what kind of system my software will be
installed and I do not know how many different user will have access over
the network I have to consider all and everything from Win98 to nowadays.

So I will try to make an install that stores the TPS depending on the OS.

IF %WINVWER% prior Vista store TPS to COMMON_DOCUMENTS\myProject\data

ELSE store TPS to PROGRAM_FILE\myProject\data



As long as a single user on one machine or even several user, with a
separate account, on one machine there seems no problem with this storing
strategy.

But what if an EXE is placed somewhere on a "central device" (Server) and
many clients have got some links on ther desktop to run this exe.
C:\Program Files\myProject\Data was the perfect palce in the past.

Last question: are there any other new rules'o'thumb for an explicit
network project?


Or will we continue as before, as long as we consider to use COM_DOC for
Vista etc and the old fashioned for XP and prior?


Sounds like this could be a suitable way then.


thx again
Wolfgang

--
Grüße / Regards
Wolfgang Orth

http://www.odata.de



Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[NewsArchive]

Hi Wolfgang,

> My experience so far with Vista is (only a few late night tests) that it
> works quite well. Its XP that is so cumbersome.

Oh dear me!!! Please don't tell that to the people who hate vista without
ever having looked at it<g>

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Jane,

> What you COULD do is have your elevated installer create your own data
> folder within COMMON_DOCUMENTS.

So did I

> Then use SB's Set Access Control script item to give EVERYONE full
> control to that folder.

> Attached is a script that I ran on an XP machine.

I am going to test it instantly and will report

To complete the weirdness:

My developmachine is with XP (me being admin)

I have installed the program and its data on Vista Business being a User
and I get that elevation dialog. Once installed the program runs well.

After deleting all stuff I logged in as Admin, did the same install. Also
had to confirm, but thats okay. One get used to all this confirmation
dialogs

But when I wanted to run the program - being ADMIN - the TPS were not in
read-write mode.....!

I had to kill that process in the taskmanager and then start the program
"As Administrator" (right mouseclick).

<headscratch>

going to test you SB6 now....



--
Grüße / Regards
Wolfgang Orth

http://www.odata.de



Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[NewsArchive]

> Then use SB's Set Access Control script item to give EVERYONE full
> control to that folder.

> Attached is a script that I ran on an XP machine.

You cause another scratching on my bold head... EVERYONE.... who is that?

You made up that EVERYONE? Or is this a specific existing variable in
Windows?

Or could I make my own? But how to attach my SPECIFICUSER to my program?

Did I again miss something basicly in Windows administration?




--
Grüße / Regards
Wolfgang Orth

http://www.odata.de



Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[NewsArchive]

Everyone is one of the "implicit" Windows groups.
It's the most inclusive, because it includes "everyone" - from administrator
to peon.

Depending on the type of setup (standalone machine, workgroup, domain) I'd
rather use Authenticated Users or mydomainname\users or something like that
for permissions.
But always safest to use Everyone (which includes Guest, if that account is
enabled) for auditing.
And since you don't know the name of the security context in which your
users are going to be installing your app, "Everyone" is a safe group to
use.

Check "implicit groups" on this page:
http://technet.microsoft.com/en-us/library/bb726980.aspx

Or try right-clicking a file on your computer and going to the Security tab.
Click Edit then Add permission, then just type "Ev" in the box (as in my
pic) and click Check Names. Windows will expand the name to Everyone
(second pic). When you hit OK, that group is added to the permissions list
and can have permissions set (third pic shows read/execute only by default).
If you look at the screen shot after running that SB6 script I posted, that
was the result on the permissions screen.

NOTE: I've never done this on a non-English machine. Don't know if they
use the same group names on other versions.

Jane

[NewsArchive]

>
> NOTE: I've never done this on a non-English machine. Don't know if they
> use the same group names on other versions.

yepp!

EVERYONE (en) = JEDER (ger)

Welcome in Babylon!









--
Grüße / Regards
Wolfgang Orth

http://www.odata.de



Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[NewsArchive]

So did my SB6 script work on your machine or did you need to change it to
JEDER ?

Jane Fleming

[NewsArchive]

> So did my SB6 script work on your machine or did you need to change it
> to JEDER ?

Indeed I had to change it to JEDER.

But I can confirm that with this change jeder, aeeeh, I mean everyone was
able to modify a TXT and save it successful!

We have two possible strategies now:

a) modification of the folder permissions by adding a new user EVERYONE /
JEDER / ....
(suitable for single language installs)

b) decide at installation time which OS we are targeting and then fill a
variable that holds the path of the data

IF %WINVER% LESS $WIN_VISTA$
MyDataDir = %Common_Documents%\MyProject\Data
ELSE
%MyDataDir% = %SB_InstallDir%\MyProject\Data
END

INSTALL FILE "source\db.TPS" TO "%MyDataDir%\db.TPS" (Always Install)

(beware: that was pseudocode as I do not have the actual variable names at
hand)

This also means we have to modify the program itself, as we have to run a
ROUTINE at the very first beginning where we have to check the actual OS
we run on and then SYSTEM{PROP:DataPath} = XP or Vista.


Thanks for sharing your insight, Jane!


--
Grüße / Regards
Wolfgang Orth

http://www.odata.de



Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[NewsArchive]

Hi Wolfgang,

>> So did my SB6 script work on your machine or did you need to change it
>> to JEDER ?
>
> Indeed I had to change it to JEDER.

This can be a potential problem when creating installs that go to the
international market. Unfortunately MS translates some of the basic names
and doesn't alwasy provide means to get the non-translated name for exact
comparisons etc. when running in a different language.

If you have to use JEDER means that if someone installs your software where
JEDER should be EVERYONE, this strategy will not work.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

>> Indeed I had to change it to JEDER.
>
> This can be a potential problem when creating installs that go to the
> international market. Unfortunately MS translates some of the basic names
> and doesn't alwasy provide means to get the non-translated name for exact
> comparisons etc. when running in a different language.
>
> If you have to use JEDER means that if someone installs your software
> where
> JEDER should be EVERYONE, this strategy will not work.

Using the security identifier (SID) should also work in SetupBuilder.
S-1-1-0 is the SID for the "Everyone" special group. The SID representing
"Everyone" is the same on every Windows machine, even if the actual name of
the group changes in different versions or localizations. S-1-1-0 is a
"universal SID" and even constant across different operating systems.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

> Using the security identifier (SID) should also work in SetupBuilder.
> S-1-1-0 is the SID for the "Everyone" special group. The SID representing
> "Everyone" is the same on every Windows machine, even if the actual name of
> the group changes in different versions or localizations. S-1-1-0 is a
> "universal SID" and even constant across different operating systems.

That is AWSOME! I remember having issues with installers back when I was
running a Danish Windows 98 and certain things were translated and made a
mess.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Didn't work for me, Friedrich.
I just got back from a 750-mile drive taking an 86-yr old friend up to her
brother's for Christmas so I'm just slightly fried <g>
Read Wolfgang's post before yours, so tried adding S-1-1-0 in an SB6 script,
but the installer did not add the Everyone group to the permissions. (I
first tried without "Betty", then with. Betty got added, Everyone did not -
pic)

I'd be interested to hear whether you can make it work. A quick Google
turned up this link to a utility that says it can set permissions based on
SIDs, but I haven't tried it: http://www.helge.mynetcologne.de/setacl/
http://setacl.sourceforge.net/

Jane Fleming

[NewsArchive]

Hi Jane,

> Didn't work for me, Friedrich.

Haven't got around to try this yet, but I did some quick research into this:

LookupAccountName is used to lookup the SID for an account.
LookupAccountSID is used to lookup the account name for a SID. Yeah, the
names look backward to me too! LookupAccountName looks up the SID.
LookupAccountSID looks up the accoutn name!!!

Anyway, here are some references from MSDN and MS:

http://msdn.microsoft.com/en-us/library/aa379159.aspx
http://msdn.microsoft.com/en-us/library/aa379166(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa379594(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa379597(VS.85).aspx
http://support.microsoft.com/kb/243330

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Jane,

> Didn't work for me, Friedrich.
> I just got back from a 750-mile drive taking an 86-yr old friend up to her
> brother's for Christmas so I'm just slightly fried <g>

<G>

> Read Wolfgang's post before yours, so tried adding S-1-1-0 in an SB6
> script, but the installer did not add the Everyone group to the
> permissions. (I first tried without "Betty", then with. Betty got
> added, Everyone did not - pic)
>
> I'd be interested to hear whether you can make it work. A quick Google
> turned up this link to a utility that says it can set permissions based on
> SIDs, but I haven't tried it: http://www.helge.mynetcologne.de/setacl/
> http://setacl.sourceforge.net/

Please enter (S-1-1-0) instead of S-1-1-0. Does this work for you?

BTW, here is an interesting list of well-known security identifiers:

http://support.microsoft.com/default.aspx/kb/243330

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

YES!

(And duh... the documentation for that screen actually illustrates using a
SID with it enclosed in parenthesis. RTFM, Jane... <g> )

Jane

[NewsArchive]

Attached script uses SID for JEDER to set permissions

Jane Fleming

[NewsArchive]

> Using the security identifier (SID) should also work in SetupBuilder.

Would it be possible that you add an example script in your next update?

And maybe a desription file what example is doing what, the names
sometimes speak for the contents, but a brief description would be very
helpful.

tia
Wolfgang




--
Grüße / Regards
Wolfgang Orth

http://www.odata.de



Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

[NewsArchive]

Hi Wolfgang,

>> Using the security identifier (SID) should also work in SetupBuilder.
>
> Would it be possible that you add an example script in your next update?
>
> And maybe a desription file what example is doing what, the names
> sometimes speak for the contents, but a brief description would be very
> helpful.

See Jane's screenshot example above and use (S-1-1-0) instead of S-1-1-0.
This should do it.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

The documentation DOES show using parenthesis around the SID.

How much of a hassle would it be for you to add some of the most common
well-known SIDs to the Ctrl+RightClick picklist for that script item?
Bet it would save you some support calls <g>

Jane

[NewsArchive]

Hi Friedrich,

> BTW, here is an interesting list of well-known security identifiers:
>
> http://support.microsoft.com/default.aspx/kb/243330

I found this one yesterday when I was looking into this and there is
definitely some interesting stuff there. Definitely worth exploring this
SID stuff.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php