Author |
Topic: Admin or user? (Read 1400 times) |
|
tooanalytical
member is offline
 
Posts: 1171
|
 |
Re: Admin or user?
« Reply #15 on: Oct 8th, 2015, 6:18pm » |
  
|
What is the command window? How do you make it show? Start, whoami into the search field,... nothing happens.
|
|
 76.216.221.34
|
|
|
|
robmcal
Senior Member
member is offline
Gender: 
Posts: 409
|
|
Re: Admin or user?
« Reply #16 on: Oct 8th, 2015, 9:37pm » |
|
on Oct 8th, 2015, 6:18pm, tooanalytical wrote:| What is the command window? How do you make it show? Start, whoami into the search field,... nothing happens. |
|
Type "Command Prompt" in the search box and the select "Command Prompt"
|
|
75.121.140.114
|
Definition of an Upgrade: Take old bugs out, put new ones in.
|
|
|
Chris Iverson
Administrator
member is online
20% Cooler
Gender:
Posts: 2343
|
|
Re: Admin or user?
« Reply #17 on: Oct 8th, 2015, 11:13pm » |
|
on Oct 8th, 2015, 6:16pm, tooanalytical wrote:This discussion is confusing. So far, I have LB (still at version 4.04) on windows Vista, and although I have some occasional trouble finding where things are going, I can at least create some dedicated folder on C: and put any files I want (copies) into it.
Any clearer explanations of installing and what will go where? |
|
I'll try.
In older versions of LB, all example files and configuration files(data, that should be user-editable) was installed in the same folder as the LB's executable code. This was easy to do in previous versions of Windows, where people had admin access by default.
Vista started enforcing the separation of admin access and user access, called the principle of least privilege. Basically, you don't get the power to make system-wide changes unless you actually need to do so.
System-wide changes can impact other users of the same system.
User-local changes will only impact the user who makes the change.
Now, long before Vista, programs were supposed to keep their executable code, which should(generally) not be user editable, installed by an admin(who is authorized to make changes to the system), and their user-editable data(configuration files, etc) in separate places.
The executable code would be stored in a place that only the system could edit, and user data would be stored in a place a regular user has access to.
However, as I said before, in home installations of XP, all users had admin access by default, so any security was completely cut out.
When Vista came out, programs had to follow the rules long since established.
LB's installer and program were modified to separate where different things got put on systems Vista+.
Executable code would be put into Program Files, only editable by an admin, as it should be. (By default, C:\Program Files (x86)\Liberty BASIC v<version>).
The user stuff(configuration files, source code examples, images needed for the demos, etc) would get copied to a folder belonging to the user. (By default, C:\Users\<username>\AppData\Roaming\Liberty BASIC v<version>).
So, for example, I install LB v4.5 using my account, Chris, which has the admin access needed to be allowed to install stuff.
LB gets put in C:\Program Files (x86)\Liberty BASIC v4.5.
The example stuff gets put in C:\Users\Chris\AppData\Roaming\Liberty BASIC v4.5.
Another thing to keep in mind is that Windows tracks each program in the system by user; EVERY program running on the system is considered to have been started by some user or another, and the access that program has depends on the access the user running the program has.
So, when I launch the installer as Chris, who as admin rights, it gets Chris's identity for the install, and puts the example stuff in the path listed above.
Then, when I launch LB itself, Windows uses the identity of the Chris account to launch LB.
<current user> = Chris
Therefore
C:\Users\<current user>\AppData\Roaming\Liberty BASIC v4.5
maps to
C:\Users\Chris\AppData\Roaming\Liberty BASIC v4.5
which is where it was placed by the installer; so there is no issue.
The issue being discussed here is when a user that didn't install LB tries to run it, even if LB is installed on the same computer. The data and configuration files got copied to a place that the new user can't access(standard users are not allowed to access each others' data.)
Let me demonstrate with another example.
Let's say you have two admin accounts on the same computer, Alice and Bob.
Alice installs Liberty BASIC. The program gets installed to the Program Files folder mentioned above, and the example code and configuration data gets copied to:
C:\Users\Alice\AppData\Roaming\Liberty BASIC v4.5.
Now, Alice tries to run LB.
Windows starts LB as Alice.
LB checks for its configuration data at:
C:\Users\<current user>\AppData\Roaming\Liberty BASIC v4.5.
Because Alice is the one running LB, it maps like this:
C:\Users\Alice\AppData\Roaming\Liberty BASIC v4.5
Which is where the data was placed, so everything works.
Now let's try Bob.
Bob starts LB.
Windows launches LB with Bob's identity.
<current user> = Bob
LB checks for it's configuration data at
C:\Users\<current user>\AppData\Roaming\Liberty BASIC v4.5
Which, currently, maps to:
C:\Users\Bob\AppData\Roaming\Liberty BASIC v4.5
Which is not where the configuration data was placed. LB will still run at this point, but all options within it will be reset, and every time Bob tries to change a setting, he will get an error message.
He will also apparently not have the sample files, because they weren't placed with him.
Now, there's one more scenario, and it's this one that caused confusion today.
When a user that does not have admin rights is logged in, and tries to do something that requires admin rights, Windows will pop up a dialog box asking for the username and password of someone who does have admin rights.
If said credentials are provided, Windows launches the program as the administrative user, NOT the standard user who tried to start it. After all, it's the admin user's access that's needed; to grant it that access, it needs to run as the admin user.
Let's see what happens in another scenario.
This time, for clarity, we'll name our two users Admin and User. Admin has admin access, User doesn't.
User is signed in to the desktop, and LB is not installed.
<current user> = User
He tries to install LB, and gets asked for admin credentials.
Admin comes over and types in his username and password. Windows starts the install of LB as Admin. Let's see what effect this has.
<current user> = Admin
Install path = C:\Program Files (x86)\Liberty BASIC v4.5
Data path = C:\Users\<current user>\AppData\Roaming\Liberty BASIC v4.5
The Data path then maps to:
C:\Users\Admin\AppData\Roaming\Liberty BASIC v4.5
So all of the configuration data, samples, etc get copied there.
After the installer closes, there is no longer a program running as Admin.
<current user> = User
Now that LB's installed, User thanks Admin and goes to start LB.
Windows starts LB with User's identity.
Data path = C:\Users\<current user>\AppData\Roaming\Liberty BASIC v4.5
which then maps to
C:\Users\User\AppData\Roaming\Liberty BASIC v4.5
Which ends up with User having the same problem as above; only it seems stranger, because, to User, he was the one who installed LB.
I hope this clears things up; Windows is an insanely complicated beast, but much of that complexity is necessary for the amount of flexibility it provides, especially for corporate users.
|
| « Last Edit: Oct 8th, 2015, 11:17pm by Chris Iverson » |
73.22.210.45
|
"Do you believe in destiny?" - Pyrrha Nikos, RWBY
"With what wish will your Soul Gem shine?" - Kyubey, Puella Magi Madoka Magica
|
|
|
Rod
Global Moderator
member is offline
Graphics = goosebumps!
Gender:
Posts: 5745
|
|
Re: Admin or user?
« Reply #18 on: Oct 9th, 2015, 01:40am » |
|
Much clearer, thanks. Having to copy the folder seems a poor solution. Particularly if the data file location is protected and the user won't even see it.
Could we write a small program that would automate the copying process? Perhaps not because it would not gain access to the folder to copy.
Is this not the role of the manifest? To escalate the permissions to allow any user to instal?
Still some reading to do for my understanding. As it stands just now the user needs admin rights to ensure a working install?
|
|
86.139.129.81
|
|
|
|
Rod
Global Moderator
member is offline
Graphics = goosebumps!
Gender:
Posts: 5745
|
|
Re: Admin or user?
« Reply #19 on: Oct 9th, 2015, 02:40am » |
|
Or, should Carl change Liberty BASIC startup routine so that it creates the required user directory if it does not exist and one time copies the default configuration. Perhaps the sample programs could be copied but if they have to exist in program files directory to be copied why not leave them there as unalterable sample files? Perhaps move the sample files online.
A newbie has no chance of dealing with these complex issues, it needs to be automatic and seamless.
|
|
86.139.129.81
|
|
|
|
nooneyouknow
New Member
member is offline
Gender:
Posts: 39
|
|
Re: Admin or user?
« Reply #20 on: Oct 9th, 2015, 03:27am » |
|
What I don't understand is why has it taken this long for the subject to come up?  I'm kind of sorry (in a way) that I brought it up today, but am enjoying the process/discussion. It means good things about Liberty Basic.
Of course, the installing program should do the copying, but even that is confusing to the uninitiated user.
Quote:| Do you want to install this program for every user on this computer or just this user? |
|
|
|
107.215.45.32
|
|
|
|
metro
Full Member
member is offline
Gender:
Posts: 204
|
|
Re: Admin or user?
« Reply #21 on: Oct 9th, 2015, 06:08am » |
|
And then we have the issue of taking all this on-board for the programs we write and distribute.
Do we store the generated data (and databases) from those programs in a sub-dir of C:\Users\<current user>\AppData\Roaming or is it better to store it in the users "MyDocuments" Folder to simplify the backup process as all information is in the one location.
|
|
220.245.192.23
|
Win10 64 HP laptop + desktop Mint Linux 64bit
|
|
|
Chris Iverson
Administrator
member is online
20% Cooler
Gender:
Posts: 2343
|
|
Re: Admin or user?
« Reply #22 on: Oct 9th, 2015, 08:04am » |
|
on Oct 9th, 2015, 01:40am, Rod wrote:| Could we write a small program that would automate the copying process? Perhaps not because it would not gain access to the folder to copy. |
|
Correct. The copying program would have to have permissions to access the folder being copied from.
on Oct 9th, 2015, 01:40am, Rod wrote:| Is this not the role of the manifest? To escalate the permissions to allow any user to instal? |
|
Not quite. The manifest simply declares that the program is compatible with the enforcement of admin access separation in Vista.
Without the manifest, Windows automatically activates a number of compatibility shims that can cause a lot of headaches when trying to sort out an issue.
on Oct 9th, 2015, 01:40am, Rod wrote:| As it stands just now the user needs admin rights to ensure a working install? |
|
Pretty much. A standard user is perfectly capable of using LB, but it needs to be installed by an Administrator.
This is how most Windows programs currently operate, anyway.
on Oct 9th, 2015, 03:27am, pnlawrence wrote:| What I don't understand is why has it taken this long for the subject to come up? I'm kind of sorry (in a way) that I brought it up today, but am enjoying the process/discussion. It means good things about Liberty Basic. |
|
Don't be sorry. These kinds of questions do need to be asked of distributed programs.
The primary reason, essentially, is that, believe it or not, no one has stumbled across this issue before.
The reason I was able to identify the cause so quickly is because of the error message you got. It's a known error message, and I've posted quite a few times on the forum on how to fix it (create the LB folder in AppData).
The detail you gave us about your setup helped narrow down what exactly was happening, from the OS's point of view.
on Oct 9th, 2015, 03:27am, pnlawrence wrote:Of course, the installing program should do the copying, but even that is confusing to the uninitiated user.
Quote:
Do you want to install this program for every user on this computer or just this user? |
|
Note that this does not do what you think it does.
When a program asks this question, if you choose "just me", what it does is, instead of installing to Program Files, it installs to C:\Users\<current user>\AppData\Local.
In this case, the person "installing" the program really is the only one that can use it.
The benefit of this kind of install is that it's possible to do without needing admin rights. The downside is that the executable files are now editable by the user running the application, which can lead to possible corruption/infection if something goes wrong.
This is less likely to happen with a program installed in Program Files, which is write-protected against standard user access.
If the person chooses "install for everyone", the program gets installed to Program Files, as usual. This needs admin rights.
However, this does not copy files/settings into every user's profile.
The reason for this is the reason I gave above: users can be added to the system at any time.
If the installer did copy files to every user's profile on install, then what happens if a user gets added to the system later?
Let's see a program that behaves like that on a system with accounts Admin, User1, and User2.
Admin installs the program.
The installer looks for and detects three user profiles on the system: Admin, User1, and User2.
It copies configuration data to each of those accounts.
After the install, each of those accounts can run the program fine.
But what happens if, after the install, Admin then creates a User3?
User3 won't have the configuration data placed in it's profile by the installer, because it didn't exist when the installer ran!
The program will break.
Though this seems like an unlikely scenario, there's one place where this situation happens daily: in corporate networks.
Using Windows systems connected to an Active Directory domain, when a user signs on with a Domain account, the account only truly exists on the Domain controller.
When a client system tries to log in, it takes the username and password the user provides, and asks the domain controller to validate the login.
DC either says "yes" or "no", depending on if the user exists, if they got their password correct, etc.
Now, if the user had never signed into that particular computer before, then it would work just like creating a new account on that computer. The user has no files, no profile, stored on that computer until that point.
Even though, to the company, their account already exists, from the point of view of that one computer, the user never existed before that one point.
So, that user would be unable to use LB, even though their account does indeed exist!
(In fact, that little part about the account existing even if the files don't can be true on a home computer, too: the full profile is not created until the account is actually signed in to. If you create an account, but don't sign in to it yet, it will look, to programs, to not exist. This is what the "preparing your desktop" step is that shows up the first time you sign in to an account on a system. It's creating a full profile for the user based on the Default profile.)
Additionally, added stuff to every user profile you can find on the computer can actually corrupt corporate domain account profiles. This actually depends on how the corporate network is set up; in particular, if a feature called Roaming Profiles is enabled on that network.
This is why the best solution is for the program to check if it's configuration data for the user exists on startup, and if it doesn't, create it. This sidesteps all of the issues listed here.
|
| « Last Edit: Oct 9th, 2015, 08:08am by Chris Iverson » |
108.171.131.187
|
"Do you believe in destiny?" - Pyrrha Nikos, RWBY
"With what wish will your Soul Gem shine?" - Kyubey, Puella Magi Madoka Magica
|
|
|
nooneyouknow
New Member
member is offline
Gender:
Posts: 39
|
|
Re: Admin or user?
« Reply #23 on: Oct 9th, 2015, 08:14am » |
|
Quote:| This is why the best solution is for the program to check if it's configuration data for the user exists on startup, and if it doesn't, create it. This sidesteps all of the issues listed here. |
|
That sounds way better.
Make it so, Number One.  
|
|
107.215.45.32
|
|
|
|
Rod
Global Moderator
member is offline
Graphics = goosebumps!
Gender:
Posts: 5745
|
|
Re: Admin or user?
« Reply #25 on: Oct 9th, 2015, 10:46am » |
|
Ok, holding onto the tail of this writhing dragon, Carl needs to change the startup routine to check for and create the user directory and configuration file if it does not exist.
Sounds like a plan. But how is the program originally installed? Can the installer force it into Program Files(x86) directory so that it is protected and available to all users or do we need to "run as admin" or will windows ask for admin confirmation?
Once we get comfortable with how to foolproof the Liberty install we can get round to recommendations for distributing programs.
So the ideal scenario is that Liberty is available on the system and that each user automatically sets their own configuration and accesses their own .bas files.
We might discuss the samples, as one set could be shared if they were central and read only. Users get their own configuration file and may save their work to their own user files area. Trying to think through the complication of sourcing and storing multiple copies of the sample files.
|
|
86.139.129.81
|
|
|
|
Chris Iverson
Administrator
member is online
20% Cooler
Gender:
Posts: 2343
|
|
Re: Admin or user?
« Reply #26 on: Oct 9th, 2015, 11:18am » |
|
on Oct 9th, 2015, 06:08am, metro wrote:And then we have the issue of taking all this on-board for the programs we write and distribute.
Do we store the generated data (and databases) from those programs in a sub-dir of C:\Users\<current user>\AppData\Roaming or is it better to store it in the users "MyDocuments" Folder to simplify the backup process as all information is in the one location.
|
|
The best explanation I have seen on the difference is here.
To quote*:
Quote:The most important difference between My Documents and Application Data is that My Documents is where users store their files, whereas Application Data is where programs store their files.
In other words, if you put something in CSIDL_MYDOCUMENTS (My Documents), you should expect the user to be renaming it, moving it, deleting it, emailing it to their friends, all the sorts of things users do with their files. Therefore, files that go there should be things that users will recognize as "their stuff". Documents they've created, music they've downloaded, that sort of thing.
On the other hand, if you put something in CSIDL_APPDATA, (AppData\Roaming), the user is less likely to be messing with it. This is where you put your program's supporting data that isn't really something you want the user messing with, but which should still be associated with the user. High score tables, program settings, customizations, spell check exceptions...
There is another directory called CSIDL_LOCAL_APPDATA (AppData\Local) which acts like CSIDL_APPDATA, except that it does not get copied if the user profile roams. (The "Local Settings" branch is not copied as part of the roaming user profile.) Think of it as a per-user-per-machine storage location. Caches and similar non-essential data should be kept here, especially if they are large. Other examples of non-roaming per-user data are your %TEMP% and Temporary Internet Files directories. |
|
Additionally, any backup program worth their salt should be backing up the user's profile, which includes the stuff in AppData.
*The bolded areas, I changed to reflect the new paths for AppData. (The names listed in the original post were the names on Windows XP; they're no longer the current names.)
|
| « Last Edit: Oct 9th, 2015, 11:21am by Chris Iverson » |
108.171.131.186
|
"Do you believe in destiny?" - Pyrrha Nikos, RWBY
"With what wish will your Soul Gem shine?" - Kyubey, Puella Magi Madoka Magica
|
|
|
Chris Iverson
Administrator
member is online
20% Cooler
Gender:
Posts: 2343
|
|
Re: Admin or user?
« Reply #27 on: Oct 9th, 2015, 11:28am » |
|
on Oct 9th, 2015, 10:46am, Rod wrote:Ok, holding onto the tail of this writhing dragon, Carl needs to change the startup routine to check for and create the user directory and configuration file if it does not exist.
Sounds like a plan. But how is the program originally installed? Can the installer force it into Program Files(x86) directory so that it is protected and available to all users or do we need to "run as admin" or will windows ask for admin confirmation? |
|
To be able to write to Program Files, the installer needs to be run as admin.
If the user isn't an administrator, they will be prompted for admin credentials when trying to run the installer.
on Oct 9th, 2015, 10:46am, Rod wrote:| So the ideal scenario is that Liberty is available on the system and that each user automatically sets their own configuration and accesses their own .bas files. |
|
I believe that would be the best case scenario.
on Oct 9th, 2015, 10:46am, Rod wrote:| We might discuss the samples, as one set could be shared if they were central and read only. Users get their own configuration file and may save their work to their own user files area. Trying to think through the complication of sourcing and storing multiple copies of the sample files. |
|
Another possibility, I believe, is the Common Application Data folder, which, by default, is a hidden folder at C:\ProgramData(on Vista+, not sure of the path on XP).
This works like the AppData folder, except it is shared among all users.
It is intended for program data that is specific to the system instead of the user.
By default, if I recall correctly(I still need to test this), it is writable by all users of the system.
You could put the sample files there, and not worry about copying them all over the place.
Downsides being, if one user changes one of the samples, all users lose the original.
You would still want config data(the ini file, etc) to be in AppData, though.
|
|
108.171.131.186
|
"Do you believe in destiny?" - Pyrrha Nikos, RWBY
"With what wish will your Soul Gem shine?" - Kyubey, Puella Magi Madoka Magica
|
|
|
|
