You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Eduardo Castro <es...@gmail.com> on 2009/04/09 19:17:09 UTC
Question about file permission
Hi,
I have an application that uses Derby and it is installed in the
Program Files folder. To install the application, it is required an
administrator user. However, after installing, if a non administrator user
tries starting the application, it can not write to the derby database, just
read. This app is shared by multiple users, non-administrator users.
Any suggestions to avoid this problem with permissions?
OS: Windows Vista
Regards,
Eduardo
Re: Question about file permission
Posted by Mark Thornton <mt...@optrak.co.uk>.
Jeff Stuckman wrote:
> PS: This has nothing to do with UAC -- even if you turn off UAC you will
> still see this behavior. The Program Files redirection feature mentioned by
> the previous poster makes it possible for sysadmins to lock down permissions
> on application binaries, while working around the broken behavior of
> programs that write data to "Program Files". (You wouldn't put a database in
> /usr/bin on a UNIX system, would you?) Unless you're updating your binaries,
> there has been no need to write to "Program Files" since Windows 98 came out
> 11 years ago...
>
Until Vista arrived this rule has frequently been broken, not least by
Microsoft themselves. For example, until recently SQLServer would put
its databases in Program Files by default.
Mark Thornton
Re: Question about file permission
Posted by Eduardo Castro <es...@gmail.com>.
Hi,
Thank you for your replies. Both messages are valid. I agree that dabase
files should not stay in the Program Files folder due to permissions that
can be denied by an administrator.
I have also an updater that changes binaires, but only administrators are
allowed to use it.
Regards,
Eduardo
2009/4/9 Tiago Espinha <ti...@espinhas.net>
> Hello Jeff,
> Just a small remark on your post. I do strongly believe this is
> UAC-related. In Windows XP your applications can freely access files in
> their program files folder as long as they are Administrators. In Windows
> Vista this behavior changed and I can't think of any other reason than UAC.
> It was in Windows Vista that I got the said symbolic link for the first
> time.
>
> To further prove my point, I have an application that runs fine on any
> XP-based system but it will crash under Vista, exactly because it tries to
> create a file in its Program Files directory. While it may not be UAC
> directly that is responsible for the symbolic link, I think it is safe to
> say that UAC is responsible for the tightened access restrictions to the
> Program Files folders.
>
> Do note, I did not at any point in my previous post advocate the usage of
> the Program Files directory as the databases folder; I do agree that for
> cleanliness' sake there are alternatives in place that ought to be used
> instead of Program Files (just like it thoroughly explains in the TechNet
> link I also posted).
>
> Tiago
>
>
> On Thu, Apr 9, 2009 at 10:36 PM, Jeff Stuckman <st...@umd.edu> wrote:
>
>> Hello,
>>
>> You should not put database files in the "Program Files" folder. The
>> "Program Files" folder is for binaries, libraries, and resource files. The
>> contents of "Program Files" should never change unless you are installing,
>> removing, or patching a program.
>>
>> If your database will be shared across multiple users, it should go in the
>> all users appdata directory, which looks something like: "C:\Documents and
>> Settings\All Users\yourprogram". In Windows Vista, the default location
>> for
>> this folder has been moved to "C:\ProgramData\yourprogram" but there is a
>> symbolic link to the old location to accommodate software which
>> incorrectly
>> hard-coded the old pathname. (Of course, you should not hardcode these
>> pathnames because users can install the OS to a different drive -- instead
>> call a function similar to SHGetKnownFolderPath)
>>
>> PS: This has nothing to do with UAC -- even if you turn off UAC you will
>> still see this behavior. The Program Files redirection feature mentioned
>> by
>> the previous poster makes it possible for sysadmins to lock down
>> permissions
>> on application binaries, while working around the broken behavior of
>> programs that write data to "Program Files". (You wouldn't put a database
>> in
>> /usr/bin on a UNIX system, would you?) Unless you're updating your
>> binaries,
>> there has been no need to write to "Program Files" since Windows 98 came
>> out
>> 11 years ago...
>>
>>
>> ---------------------
>> From: Eduardo Castro [mailto:estima@gmail.com]
>> Sent: Thursday, April 09, 2009 1:17 PM
>> To: derby-user@db.apache.org
>> Subject: Question about file permission
>>
>> Hi,
>>
>> I have an application that uses Derby and it is installed in the
>> Program Files folder. To install the application, it is required an
>> administrator user. However, after installing, if a non administrator user
>> tries starting the application, it can not write to the derby database,
>> just
>> read. This app is shared by multiple users, non-administrator users.
>>
>> Any suggestions to avoid this problem with permissions?
>>
>> OS: Windows Vista
>>
>> Regards,
>> Eduardo
>>
>>
>
Re: Question about file permission
Posted by Tiago Espinha <ti...@espinhas.net>.
Hello Jeff,
Just a small remark on your post. I do strongly believe this is UAC-related.
In Windows XP your applications can freely access files in their program
files folder as long as they are Administrators. In Windows Vista this
behavior changed and I can't think of any other reason than UAC. It was in
Windows Vista that I got the said symbolic link for the first time.
To further prove my point, I have an application that runs fine on any
XP-based system but it will crash under Vista, exactly because it tries to
create a file in its Program Files directory. While it may not be UAC
directly that is responsible for the symbolic link, I think it is safe to
say that UAC is responsible for the tightened access restrictions to the
Program Files folders.
Do note, I did not at any point in my previous post advocate the usage of
the Program Files directory as the databases folder; I do agree that for
cleanliness' sake there are alternatives in place that ought to be used
instead of Program Files (just like it thoroughly explains in the TechNet
link I also posted).
Tiago
On Thu, Apr 9, 2009 at 10:36 PM, Jeff Stuckman <st...@umd.edu> wrote:
> Hello,
>
> You should not put database files in the "Program Files" folder. The
> "Program Files" folder is for binaries, libraries, and resource files. The
> contents of "Program Files" should never change unless you are installing,
> removing, or patching a program.
>
> If your database will be shared across multiple users, it should go in the
> all users appdata directory, which looks something like: "C:\Documents and
> Settings\All Users\yourprogram". In Windows Vista, the default location for
> this folder has been moved to "C:\ProgramData\yourprogram" but there is a
> symbolic link to the old location to accommodate software which incorrectly
> hard-coded the old pathname. (Of course, you should not hardcode these
> pathnames because users can install the OS to a different drive -- instead
> call a function similar to SHGetKnownFolderPath)
>
> PS: This has nothing to do with UAC -- even if you turn off UAC you will
> still see this behavior. The Program Files redirection feature mentioned by
> the previous poster makes it possible for sysadmins to lock down
> permissions
> on application binaries, while working around the broken behavior of
> programs that write data to "Program Files". (You wouldn't put a database
> in
> /usr/bin on a UNIX system, would you?) Unless you're updating your
> binaries,
> there has been no need to write to "Program Files" since Windows 98 came
> out
> 11 years ago...
>
>
> ---------------------
> From: Eduardo Castro [mailto:estima@gmail.com]
> Sent: Thursday, April 09, 2009 1:17 PM
> To: derby-user@db.apache.org
> Subject: Question about file permission
>
> Hi,
>
> I have an application that uses Derby and it is installed in the
> Program Files folder. To install the application, it is required an
> administrator user. However, after installing, if a non administrator user
> tries starting the application, it can not write to the derby database,
> just
> read. This app is shared by multiple users, non-administrator users.
>
> Any suggestions to avoid this problem with permissions?
>
> OS: Windows Vista
>
> Regards,
> Eduardo
>
>
RE: Question about file permission
Posted by Jeff Stuckman <st...@umd.edu>.
Hello,
You should not put database files in the "Program Files" folder. The
"Program Files" folder is for binaries, libraries, and resource files. The
contents of "Program Files" should never change unless you are installing,
removing, or patching a program.
If your database will be shared across multiple users, it should go in the
all users appdata directory, which looks something like: "C:\Documents and
Settings\All Users\yourprogram". In Windows Vista, the default location for
this folder has been moved to "C:\ProgramData\yourprogram" but there is a
symbolic link to the old location to accommodate software which incorrectly
hard-coded the old pathname. (Of course, you should not hardcode these
pathnames because users can install the OS to a different drive -- instead
call a function similar to SHGetKnownFolderPath)
PS: This has nothing to do with UAC -- even if you turn off UAC you will
still see this behavior. The Program Files redirection feature mentioned by
the previous poster makes it possible for sysadmins to lock down permissions
on application binaries, while working around the broken behavior of
programs that write data to "Program Files". (You wouldn't put a database in
/usr/bin on a UNIX system, would you?) Unless you're updating your binaries,
there has been no need to write to "Program Files" since Windows 98 came out
11 years ago...
---------------------
From: Eduardo Castro [mailto:estima@gmail.com]
Sent: Thursday, April 09, 2009 1:17 PM
To: derby-user@db.apache.org
Subject: Question about file permission
Hi,
I have an application that uses Derby and it is installed in the
Program Files folder. To install the application, it is required an
administrator user. However, after installing, if a non administrator user
tries starting the application, it can not write to the derby database, just
read. This app is shared by multiple users, non-administrator users.
Any suggestions to avoid this problem with permissions?
OS: Windows Vista
Regards,
Eduardo
Re: Question about file permission
Posted by Tiago Espinha <ti...@espinhas.net>.
Hello Eduardo,
Windows Vista is a tricky operating system because of its UAC feature. The
last time I had to fiddle with it, it seemed to have some sort of heuristics
that automagically moved files created by applications from their C:\Program
Files\<folder> into a folder that was accessible by your current user.
This feature seems to be pretty flawed though and it is recommended that if
you are planning on full Vista compatibility, that you pick a folder for
your databases that is accessible by the user who will use the application.
I believe that the way to go with this on Vista is through the roaming
folders ( http://technet.microsoft.com/en-us/library/cc766489.aspx ).
>From Derby's perspective this is actually rather easy to achieve. You just
need to set the following property when starting Derby:
-Dderby.system.home=<directory_for_your_database>
Set it to a folder where the user actually has permissions and you should no
longer have an issue.
Hope it helps,
Tiago
On Thu, Apr 9, 2009 at 6:17 PM, Eduardo Castro <es...@gmail.com> wrote:
> Hi,
>
> I have an application that uses Derby and it is installed in the
> Program Files folder. To install the application, it is required an
> administrator user. However, after installing, if a non administrator user
> tries starting the application, it can not write to the derby database, just
> read. This app is shared by multiple users, non-administrator users.
>
> Any suggestions to avoid this problem with permissions?
>
> OS: Windows Vista
>
> Regards,
> Eduardo
>