[REQ] Change the new "User Access Rights" Feature

[MesserJocke]

Hi

1st of all: This new Version of TC ROCKS!!! This great App gets even more.... [fill in more praise]

My topic: The new feature to access files&folders with different user rights is a great idea and works very good. But i would change the following:
-> When accessing a folder where i even doesn't have read-rights, i can use "Administrator" with PW. So far so good. But TC wrote permanently read-rights for me there.... This shouldn't happen.

Also, after doing stuff with this restricted folder, i should be able to withdraw this special access (security reasons).

But all in all: great job, Christian!!!

MJ

[Lefteous]

2MesserJocke
How would you define "after doing stuff" and how should the user tell TC this?

[MesserJocke]

OK
Example:

There is a folder like c:\secret\ where i dont have read access. But i want to copy a file into it.

So i open this folder; <ALERT - No READ ALLOWED>; using Admin-user/pw; <CLEAR>; folder now open; i copy the file; <ALERT NO WRITE ALLOWED>; again using Admin-user/pw; <CLEAR>; leaving the folder; re-enter the folder <ALERT - No READ ALLOWED> .... and so on.

Short: TC should always ask me for Admin for Read attempts (this is what I meant with 'withdraw') like what it does with the write attempts.

MJ

[ghisler(Author)]

Well, I implemented this as it is implemented in Windows Vista Explorer now. I would prefer a temporary solution too, but asking the user each time for each directory read is just not feasible. TC refreshes the current directory each time you switch to it - it would make users mad if they had to confirm that every time!

Any better ideas?

[Sir_SiLvA]

make optional like
KeepUserRights =
0 = Default as its now
1 = Allways ask

[ghisler(Author)]

This doesn't help - if I don't set the rights to the folder, you cannot do much with that folder except for listing the files:
- icons will not display
- thumbnails will not display either
- files cannot be viewed
- files cannot be copied anywhere
etc. etc.

[aksdb]

How about spawning a new process in the background that handles these operations but is started under the administrator account? TC could interfere with this process (via a pipe, shared memory, or whatever) and initiate all required actions (writing, reading).

A far less complicated possibility (but somewhat "hacky") would be to remove the rights from the folder after leaving it. But I guess that would be too risky (for example if a crash occured).

[ghisler(Author)]

How about spawning a new process in the background that handles these operations but is started under the administrator account?

I'm already doing this. It's just not feasible to write every single function in TC twice.

[wanderer]

it would make users mad if they had to confirm that every time!

Probably. You could perhaps keep the user/pwd in memory for an INI-definable amount of time (having a 2-3 minutes default value). Of course then you might want to make sure they're encrypted (in memory) for security reasons, etc...

[aksdb]

How about spawning a new process in the background that handles these operations but is started under the administrator account?

I'm already doing this. It's just not feasible to write every single function in TC twice.

So I guess you also don't like the idea of putting these functions in a DLL to be used by both programs/processes? So you have all functions only once and depending on the situation TC uses them itself and if necessary it spawns the new process to call the functions and return the result.

[Eddie1506]

Don't know if this is solved or not, but one solution might be to keep permissions until TC is closed.

This way, you do what you have to with restricted folder, close it, reopen TC and voila, no access anymore.

[wanderer]

Don't know if this is solved or not, but one solution might be to keep permissions until TC is closed.

This way, you do what you have to with restricted folder, close it, reopen TC and voila, no access anymore.

Not a good idea. This feature has been implemented by MS both for security reasons and for helping the user. The way you are describing it, you ignore security reasons for user friendliness. If you let TC open after giving the password and then leave your PC for i.e. 1 hour, anyone can have access to it. There should probably be a timeout for this. If the password hasn't been used for X seconds/minutes, it should be reset and re-asked.

In all of this, there is also one other matter: what if you are using 5 instances of TC? Should you be asked for the password by each instance? Perhaps a solution similar to the one aksdb proposed might be better after all.

[ghisler(Author)]

In Beta 2, the access remains allowed until the timeout occurs, which can be set via

AdminTimeout=

in Wincmd.ini. Default is 2 (2 Minutes).

[Lefteous]

2ghisler(Author)

Default is 2 (2 Minutes).

I thought it's set in seconds (default = 180)?

[ghisler(Author)]

You are right, sorry! I had just made some tests with very short timeouts.