Sign in with
Sign up | Sign in
Your question

Why Are "Permission Entries" changed

Last response: in Windows 2000/NT
Share
Anonymous
a b 8 Security
March 8, 2005 8:16:38 PM

Archived from groups: microsoft.public.win2000.security (More info?)

I have an application that requires username "Everyone" to be granted
permission for a MS Access database file. But everytime I run the MS Access
Repair/Compact tool (to eliminate database corruption and free up space)
username "Everyone" is removed from the "Permission Entries" list for the
database file.

Why? And how can I configure the security on that database file so this
doesn't happen?
Thanks
March 9, 2005 6:56:22 PM

Archived from groups: microsoft.public.win2000.security (More info?)

If you are setting the permissions on the actual database file then the
answer is obvious.

The compression routine works like follows (well, this is how it should
work):

MDB ==> Compressed MDB
MDB ==> renamed temp file (.BAK usually)
Compressed MDB ==> renamed to original MDB
The reason for this convoluted approach is that the MDB file does not get
deleted until there is a known good compressed file in existance - if the
process fails, it just leaves the original MDB file in place.

If you indicate you want to keep the backup (depends on the utility) then
the .BAK stays and will have the permissions you have set.

Since the new MDB was created from scratch during the first step, it
inherits its permissions from the file store container it is in.

The solution is simple: grant the permissions to the containing folder. If
you are hesitent to do this because of what else is contained in the folder,
then move the MDB file to a dedicated folder and set the permissions on it.

Personally, I would raise this as a bug with the software vendors as NO
software should require the EVERYONE group to have permissions to anything
(IMHO).

- Tim





"Ken Winters" <kwinters@olympus.net> wrote in message
news:112sjjknte15819@corp.supernews.com...
>I have an application that requires username "Everyone" to be granted
>permission for a MS Access database file. But everytime I run the MS
>Access Repair/Compact tool (to eliminate database corruption and free up
>space) username "Everyone" is removed from the "Permission Entries" list
>for the database file.
>
> Why? And how can I configure the security on that database file so this
> doesn't happen?
> Thanks
>
Anonymous
a b 8 Security
March 9, 2005 6:56:23 PM

Archived from groups: microsoft.public.win2000.security (More info?)

I am setting the permissions on the actual database file, but your answer
isn't the case (it was one of my first thoughts too). I can create a new
database in the same folder (which has "Everyone" on it's access list),
open, edit, and save that database repeatedly. "Everyone" remains on it's
access list. But as soon as I run the MS Access Repair/Compact utility it
removes "Everyone" (along with any other non-Administrator users) from the
access list.

I agree that there's an underlying bug, but I don't have the opportunity to
deal with that. I'm simply trying to provide some end users with the
ability to repair/compact the database without making them also manually add
"Everyone" back to the access list.

Thanks,
Ken

"Tim" <Tim@NoSpam.com> wrote in message news:D 0lo7m$k2p$1@lust.ihug.co.nz...
> If you are setting the permissions on the actual database file then the
> answer is obvious.
>
> The compression routine works like follows (well, this is how it should
> work):
>
> MDB ==> Compressed MDB
> MDB ==> renamed temp file (.BAK usually)
> Compressed MDB ==> renamed to original MDB
> The reason for this convoluted approach is that the MDB file does not get
> deleted until there is a known good compressed file in existance - if the
> process fails, it just leaves the original MDB file in place.
>
> If you indicate you want to keep the backup (depends on the utility) then
> the .BAK stays and will have the permissions you have set.
>
> Since the new MDB was created from scratch during the first step, it
> inherits its permissions from the file store container it is in.
>
> The solution is simple: grant the permissions to the containing folder. If
> you are hesitent to do this because of what else is contained in the
> folder, then move the MDB file to a dedicated folder and set the
> permissions on it.
>
> Personally, I would raise this as a bug with the software vendors as NO
> software should require the EVERYONE group to have permissions to anything
> (IMHO).
>
> - Tim
>
>
>
>
>
> "Ken Winters" <kwinters@olympus.net> wrote in message
> news:112sjjknte15819@corp.supernews.com...
>>I have an application that requires username "Everyone" to be granted
>>permission for a MS Access database file. But everytime I run the MS
>>Access Repair/Compact tool (to eliminate database corruption and free up
>>space) username "Everyone" is removed from the "Permission Entries" list
>>for the database file.
>>
>> Why? And how can I configure the security on that database file so this
>> doesn't happen?
>> Thanks
>>
>
>
Related resources
Anonymous
a b 8 Security
March 9, 2005 6:56:24 PM

Archived from groups: microsoft.public.win2000.security (More info?)

The answer, explaination, and work-around by defining a dedicated
folder to hold the mdb with the permissions needed set on the folder
are all correct.

--
Roger Abell
Microsoft MVP (Windows Server System: Security)
MCDBA, MCSE W2k3+W2k+Nt4
"Ken Winters" <kwinters@olympus.net> wrote in message
news:112srgfmngp6b50@corp.supernews.com...
>I am setting the permissions on the actual database file, but your answer
>isn't the case (it was one of my first thoughts too). I can create a new
>database in the same folder (which has "Everyone" on it's access list),
>open, edit, and save that database repeatedly. "Everyone" remains on it's
>access list. But as soon as I run the MS Access Repair/Compact utility it
>removes "Everyone" (along with any other non-Administrator users) from the
>access list.
>
> I agree that there's an underlying bug, but I don't have the opportunity
> to deal with that. I'm simply trying to provide some end users with the
> ability to repair/compact the database without making them also manually
> add "Everyone" back to the access list.
>
> Thanks,
> Ken
>
> "Tim" <Tim@NoSpam.com> wrote in message
> news:D 0lo7m$k2p$1@lust.ihug.co.nz...
>> If you are setting the permissions on the actual database file then the
>> answer is obvious.
>>
>> The compression routine works like follows (well, this is how it should
>> work):
>>
>> MDB ==> Compressed MDB
>> MDB ==> renamed temp file (.BAK usually)
>> Compressed MDB ==> renamed to original MDB
>> The reason for this convoluted approach is that the MDB file does not get
>> deleted until there is a known good compressed file in existance - if the
>> process fails, it just leaves the original MDB file in place.
>>
>> If you indicate you want to keep the backup (depends on the utility) then
>> the .BAK stays and will have the permissions you have set.
>>
>> Since the new MDB was created from scratch during the first step, it
>> inherits its permissions from the file store container it is in.
>>
>> The solution is simple: grant the permissions to the containing folder.
>> If you are hesitent to do this because of what else is contained in the
>> folder, then move the MDB file to a dedicated folder and set the
>> permissions on it.
>>
>> Personally, I would raise this as a bug with the software vendors as NO
>> software should require the EVERYONE group to have permissions to
>> anything (IMHO).
>>
>> - Tim
>>
>>
>>
>>
>>
>> "Ken Winters" <kwinters@olympus.net> wrote in message
>> news:112sjjknte15819@corp.supernews.com...
>>>I have an application that requires username "Everyone" to be granted
>>>permission for a MS Access database file. But everytime I run the MS
>>>Access Repair/Compact tool (to eliminate database corruption and free up
>>>space) username "Everyone" is removed from the "Permission Entries" list
>>>for the database file.
>>>
>>> Why? And how can I configure the security on that database file so this
>>> doesn't happen?
>>> Thanks
>>>
>>
>>
>
>
Anonymous
a b 8 Security
March 9, 2005 6:56:25 PM

Archived from groups: microsoft.public.win2000.security (More info?)

While I appreciate your effort, merely asserting something I've already
tried will work doesn't change the fact that it doesn't. There is something
more to it.

The security settings on the folder make no difference on what happens when
the Access Repair/Compact is performed.
Thanks anyways.

Any other thoughts? Ideas?


"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:%23LDQt7GJFHA.3812@TK2MSFTNGP10.phx.gbl...
> The answer, explaination, and work-around by defining a dedicated
> folder to hold the mdb with the permissions needed set on the folder
> are all correct.
>
> --
> Roger Abell
> Microsoft MVP (Windows Server System: Security)
> MCDBA, MCSE W2k3+W2k+Nt4
> "Ken Winters" <kwinters@olympus.net> wrote in message
> news:112srgfmngp6b50@corp.supernews.com...
>>I am setting the permissions on the actual database file, but your answer
>>isn't the case (it was one of my first thoughts too). I can create a new
>>database in the same folder (which has "Everyone" on it's access list),
>>open, edit, and save that database repeatedly. "Everyone" remains on it's
>>access list. But as soon as I run the MS Access Repair/Compact utility it
>>removes "Everyone" (along with any other non-Administrator users) from the
>>access list.
>>
>> I agree that there's an underlying bug, but I don't have the opportunity
>> to deal with that. I'm simply trying to provide some end users with the
>> ability to repair/compact the database without making them also manually
>> add "Everyone" back to the access list.
>>
>> Thanks,
>> Ken
>>
>> "Tim" <Tim@NoSpam.com> wrote in message
>> news:D 0lo7m$k2p$1@lust.ihug.co.nz...
>>> If you are setting the permissions on the actual database file then the
>>> answer is obvious.
>>>
>>> The compression routine works like follows (well, this is how it should
>>> work):
>>>
>>> MDB ==> Compressed MDB
>>> MDB ==> renamed temp file (.BAK usually)
>>> Compressed MDB ==> renamed to original MDB
>>> The reason for this convoluted approach is that the MDB file does not
>>> get deleted until there is a known good compressed file in existance -
>>> if the process fails, it just leaves the original MDB file in place.
>>>
>>> If you indicate you want to keep the backup (depends on the utility)
>>> then the .BAK stays and will have the permissions you have set.
>>>
>>> Since the new MDB was created from scratch during the first step, it
>>> inherits its permissions from the file store container it is in.
>>>
>>> The solution is simple: grant the permissions to the containing folder.
>>> If you are hesitent to do this because of what else is contained in the
>>> folder, then move the MDB file to a dedicated folder and set the
>>> permissions on it.
>>>
>>> Personally, I would raise this as a bug with the software vendors as NO
>>> software should require the EVERYONE group to have permissions to
>>> anything (IMHO).
>>>
>>> - Tim
>>>
>>>
>>>
>>>
>>>
>>> "Ken Winters" <kwinters@olympus.net> wrote in message
>>> news:112sjjknte15819@corp.supernews.com...
>>>>I have an application that requires username "Everyone" to be granted
>>>>permission for a MS Access database file. But everytime I run the MS
>>>>Access Repair/Compact tool (to eliminate database corruption and free up
>>>>space) username "Everyone" is removed from the "Permission Entries" list
>>>>for the database file.
>>>>
>>>> Why? And how can I configure the security on that database file so
>>>> this doesn't happen?
>>>> Thanks
>>>>
>>>
>>>
>>
>>
>
>
Anonymous
a b 8 Security
March 9, 2005 6:56:25 PM

Archived from groups: microsoft.public.win2000.security (More info?)

I found the problem on an other newsgroup. It was the security settings in
the TEMP folder. Access apparently uses this folder to create a new copy of
the file during the repair/compact process.

"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:%23LDQt7GJFHA.3812@TK2MSFTNGP10.phx.gbl...
> The answer, explaination, and work-around by defining a dedicated
> folder to hold the mdb with the permissions needed set on the folder
> are all correct.
>
> --
> Roger Abell
> Microsoft MVP (Windows Server System: Security)
> MCDBA, MCSE W2k3+W2k+Nt4
> "Ken Winters" <kwinters@olympus.net> wrote in message
> news:112srgfmngp6b50@corp.supernews.com...
>>I am setting the permissions on the actual database file, but your answer
>>isn't the case (it was one of my first thoughts too). I can create a new
>>database in the same folder (which has "Everyone" on it's access list),
>>open, edit, and save that database repeatedly. "Everyone" remains on it's
>>access list. But as soon as I run the MS Access Repair/Compact utility it
>>removes "Everyone" (along with any other non-Administrator users) from the
>>access list.
>>
>> I agree that there's an underlying bug, but I don't have the opportunity
>> to deal with that. I'm simply trying to provide some end users with the
>> ability to repair/compact the database without making them also manually
>> add "Everyone" back to the access list.
>>
>> Thanks,
>> Ken
>>
>> "Tim" <Tim@NoSpam.com> wrote in message
>> news:D 0lo7m$k2p$1@lust.ihug.co.nz...
>>> If you are setting the permissions on the actual database file then the
>>> answer is obvious.
>>>
>>> The compression routine works like follows (well, this is how it should
>>> work):
>>>
>>> MDB ==> Compressed MDB
>>> MDB ==> renamed temp file (.BAK usually)
>>> Compressed MDB ==> renamed to original MDB
>>> The reason for this convoluted approach is that the MDB file does not
>>> get deleted until there is a known good compressed file in existance -
>>> if the process fails, it just leaves the original MDB file in place.
>>>
>>> If you indicate you want to keep the backup (depends on the utility)
>>> then the .BAK stays and will have the permissions you have set.
>>>
>>> Since the new MDB was created from scratch during the first step, it
>>> inherits its permissions from the file store container it is in.
>>>
>>> The solution is simple: grant the permissions to the containing folder.
>>> If you are hesitent to do this because of what else is contained in the
>>> folder, then move the MDB file to a dedicated folder and set the
>>> permissions on it.
>>>
>>> Personally, I would raise this as a bug with the software vendors as NO
>>> software should require the EVERYONE group to have permissions to
>>> anything (IMHO).
>>>
>>> - Tim
>>>
>>>
>>>
>>>
>>>
>>> "Ken Winters" <kwinters@olympus.net> wrote in message
>>> news:112sjjknte15819@corp.supernews.com...
>>>>I have an application that requires username "Everyone" to be granted
>>>>permission for a MS Access database file. But everytime I run the MS
>>>>Access Repair/Compact tool (to eliminate database corruption and free up
>>>>space) username "Everyone" is removed from the "Permission Entries" list
>>>>for the database file.
>>>>
>>>> Why? And how can I configure the security on that database file so
>>>> this doesn't happen?
>>>> Thanks
>>>>
>>>
>>>
>>
>>
>
>
March 10, 2005 7:54:53 PM

Archived from groups: microsoft.public.win2000.security (More info?)

Thats odd - I never noticed this before. You used to be able to watch it do
the compact / repair within the same folder.
(Oh frigging Winzip I say since it does something similar - unzip a GB file
and it has to unzip it elsewhere then waste time copying it to the right
place).

Another method of doing the compact that you may not be aware of is via the
ODBC Administrator. There are also utilities around that will do it for
you - pick carefully though as any utility that COPIES the mdb to a new file
first then compacts will risk corrupting the database as the database is
usually opened with Shared Write access so may be in the progress of being
updated while the COPY is done. I have seen that happen on a production
medical system with corrupt DB as a result...

Regards,

- Tim


"Ken Winters" <kwinters@olympus.net> wrote in message
news:112uhmkbhgaug51@corp.supernews.com...
>I found the problem on an other newsgroup. It was the security settings in
>the TEMP folder. Access apparently uses this folder to create a new copy
>of the file during the repair/compact process.
>
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:%23LDQt7GJFHA.3812@TK2MSFTNGP10.phx.gbl...
>> The answer, explaination, and work-around by defining a dedicated
>> folder to hold the mdb with the permissions needed set on the folder
>> are all correct.
>>
>> --
>> Roger Abell
>> Microsoft MVP (Windows Server System: Security)
>> MCDBA, MCSE W2k3+W2k+Nt4
>> "Ken Winters" <kwinters@olympus.net> wrote in message
>> news:112srgfmngp6b50@corp.supernews.com...
>>>I am setting the permissions on the actual database file, but your answer
>>>isn't the case (it was one of my first thoughts too). I can create a new
>>>database in the same folder (which has "Everyone" on it's access list),
>>>open, edit, and save that database repeatedly. "Everyone" remains on
>>>it's access list. But as soon as I run the MS Access Repair/Compact
>>>utility it removes "Everyone" (along with any other non-Administrator
>>>users) from the access list.
>>>
>>> I agree that there's an underlying bug, but I don't have the opportunity
>>> to deal with that. I'm simply trying to provide some end users with the
>>> ability to repair/compact the database without making them also manually
>>> add "Everyone" back to the access list.
>>>
>>> Thanks,
>>> Ken
>>>
>>> "Tim" <Tim@NoSpam.com> wrote in message
>>> news:D 0lo7m$k2p$1@lust.ihug.co.nz...
>>>> If you are setting the permissions on the actual database file then the
>>>> answer is obvious.
>>>>
>>>> The compression routine works like follows (well, this is how it should
>>>> work):
>>>>
>>>> MDB ==> Compressed MDB
>>>> MDB ==> renamed temp file (.BAK usually)
>>>> Compressed MDB ==> renamed to original MDB
>>>> The reason for this convoluted approach is that the MDB file does not
>>>> get deleted until there is a known good compressed file in existance -
>>>> if the process fails, it just leaves the original MDB file in place.
>>>>
>>>> If you indicate you want to keep the backup (depends on the utility)
>>>> then the .BAK stays and will have the permissions you have set.
>>>>
>>>> Since the new MDB was created from scratch during the first step, it
>>>> inherits its permissions from the file store container it is in.
>>>>
>>>> The solution is simple: grant the permissions to the containing folder.
>>>> If you are hesitent to do this because of what else is contained in the
>>>> folder, then move the MDB file to a dedicated folder and set the
>>>> permissions on it.
>>>>
>>>> Personally, I would raise this as a bug with the software vendors as NO
>>>> software should require the EVERYONE group to have permissions to
>>>> anything (IMHO).
>>>>
>>>> - Tim
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> "Ken Winters" <kwinters@olympus.net> wrote in message
>>>> news:112sjjknte15819@corp.supernews.com...
>>>>>I have an application that requires username "Everyone" to be granted
>>>>>permission for a MS Access database file. But everytime I run the MS
>>>>>Access Repair/Compact tool (to eliminate database corruption and free
>>>>>up space) username "Everyone" is removed from the "Permission Entries"
>>>>>list for the database file.
>>>>>
>>>>> Why? And how can I configure the security on that database file so
>>>>> this doesn't happen?
>>>>> Thanks
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Anonymous
a b 8 Security
March 10, 2005 7:54:54 PM

Archived from groups: microsoft.public.win2000.security (More info?)

I am in the same boat Tim, having watched it create the compacted
in the same folder. Perhaps after years of wishing Office products
actually used %temp% the wish is now granted in a way that will make
some things harder !!! Go figure.

--
Roger
"Tim" <Tim@NoSpam.com> wrote in message news:D 0og1b$doc$1@lust.ihug.co.nz...
> Thats odd - I never noticed this before. You used to be able to watch it
> do the compact / repair within the same folder.
> (Oh frigging Winzip I say since it does something similar - unzip a GB
> file and it has to unzip it elsewhere then waste time copying it to the
> right place).
>
> Another method of doing the compact that you may not be aware of is via
> the ODBC Administrator. There are also utilities around that will do it
> for you - pick carefully though as any utility that COPIES the mdb to a
> new file first then compacts will risk corrupting the database as the
> database is usually opened with Shared Write access so may be in the
> progress of being updated while the COPY is done. I have seen that happen
> on a production medical system with corrupt DB as a result...
>
> Regards,
>
> - Tim
>
>
> "Ken Winters" <kwinters@olympus.net> wrote in message
> news:112uhmkbhgaug51@corp.supernews.com...
>>I found the problem on an other newsgroup. It was the security settings
>>in the TEMP folder. Access apparently uses this folder to create a new
>>copy of the file during the repair/compact process.
>>
>> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
>> news:%23LDQt7GJFHA.3812@TK2MSFTNGP10.phx.gbl...
>>> The answer, explaination, and work-around by defining a dedicated
>>> folder to hold the mdb with the permissions needed set on the folder
>>> are all correct.
>>>
>>> --
>>> Roger Abell
>>> Microsoft MVP (Windows Server System: Security)
>>> MCDBA, MCSE W2k3+W2k+Nt4
>>> "Ken Winters" <kwinters@olympus.net> wrote in message
>>> news:112srgfmngp6b50@corp.supernews.com...
>>>>I am setting the permissions on the actual database file, but your
>>>>answer isn't the case (it was one of my first thoughts too). I can
>>>>create a new database in the same folder (which has "Everyone" on it's
>>>>access list), open, edit, and save that database repeatedly. "Everyone"
>>>>remains on it's access list. But as soon as I run the MS Access
>>>>Repair/Compact utility it removes "Everyone" (along with any other
>>>>non-Administrator users) from the access list.
>>>>
>>>> I agree that there's an underlying bug, but I don't have the
>>>> opportunity to deal with that. I'm simply trying to provide some end
>>>> users with the ability to repair/compact the database without making
>>>> them also manually add "Everyone" back to the access list.
>>>>
>>>> Thanks,
>>>> Ken
>>>>
>>>> "Tim" <Tim@NoSpam.com> wrote in message
>>>> news:D 0lo7m$k2p$1@lust.ihug.co.nz...
>>>>> If you are setting the permissions on the actual database file then
>>>>> the answer is obvious.
>>>>>
>>>>> The compression routine works like follows (well, this is how it
>>>>> should work):
>>>>>
>>>>> MDB ==> Compressed MDB
>>>>> MDB ==> renamed temp file (.BAK usually)
>>>>> Compressed MDB ==> renamed to original MDB
>>>>> The reason for this convoluted approach is that the MDB file does not
>>>>> get deleted until there is a known good compressed file in existance -
>>>>> if the process fails, it just leaves the original MDB file in place.
>>>>>
>>>>> If you indicate you want to keep the backup (depends on the utility)
>>>>> then the .BAK stays and will have the permissions you have set.
>>>>>
>>>>> Since the new MDB was created from scratch during the first step, it
>>>>> inherits its permissions from the file store container it is in.
>>>>>
>>>>> The solution is simple: grant the permissions to the containing
>>>>> folder. If you are hesitent to do this because of what else is
>>>>> contained in the folder, then move the MDB file to a dedicated folder
>>>>> and set the permissions on it.
>>>>>
>>>>> Personally, I would raise this as a bug with the software vendors as
>>>>> NO software should require the EVERYONE group to have permissions to
>>>>> anything (IMHO).
>>>>>
>>>>> - Tim
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> "Ken Winters" <kwinters@olympus.net> wrote in message
>>>>> news:112sjjknte15819@corp.supernews.com...
>>>>>>I have an application that requires username "Everyone" to be granted
>>>>>>permission for a MS Access database file. But everytime I run the MS
>>>>>>Access Repair/Compact tool (to eliminate database corruption and free
>>>>>>up space) username "Everyone" is removed from the "Permission Entries"
>>>>>>list for the database file.
>>>>>>
>>>>>> Why? And how can I configure the security on that database file so
>>>>>> this doesn't happen?
>>>>>> Thanks
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
!