Look at the article from Erland:
http://www.sommarskog.se/share_data.html
HTH, jens Suessmeyer.
sqlLook at the article from Erland:
http://www.sommarskog.se/share_data.html
HTH, jens Suessmeyer.
sqlI need some help with implenting the following:
I recently migrated from access to sql server and i now i want to use
maintainable permissions on my tables, views, etc. The access database will
serve as a front-end.
I've created for testing purposes an testaccount with only a public role to
access to my database.
Now the hard part is when i want users to select and manipulate the data
through views and stored procedures.I want only permissions set on views and
stored procedures. The reason for this is because i don't want users to get
the data directly from tables by means of linking or importing them to
access
or other databases. Only views and stored procedures can be used.
Unfortunelately it doesn't work how i wanted to. When i open a view which is
linked in access as a table, i'm getting a message that the underlying table
has not the appropiate permissions.
Now there should be a way to apply a maintainable security, so if i could
have some advice and maybe an example on this matter i would be very
thankful.Try creating the view with the VIEW_METADATA option. This way, Access will
use view meta data instead of meta data from the underlying base tables.
See CREATE VIEW in the Books Online for more information.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Ezekil" <ezekil@.lycos.com> wrote in message
news:411d05d7$0$195$cd19a363@.news.wanadoo.nl...
> Hello,
> I need some help with implenting the following:
> I recently migrated from access to sql server and i now i want to use
> maintainable permissions on my tables, views, etc. The access database
will
> serve as a front-end.
> I've created for testing purposes an testaccount with only a public role
to
> access to my database.
> Now the hard part is when i want users to select and manipulate the data
> through views and stored procedures.I want only permissions set on views
and
> stored procedures. The reason for this is because i don't want users to
get
> the data directly from tables by means of linking or importing them to
> access
> or other databases. Only views and stored procedures can be used.
> Unfortunelately it doesn't work how i wanted to. When i open a view which
is
> linked in access as a table, i'm getting a message that the underlying
table
> has not the appropiate permissions.
> Now there should be a way to apply a maintainable security, so if i could
> have some advice and maybe an example on this matter i would be very
> thankful.|||Hi Dan,
I've looked it up in BOL but it is not very clear. Could you provide me an
example?
Thnx
"Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
news:wxfTc.20463$9Y6.12982@.newsread1.news.pas.eart hlink.net...
> Try creating the view with the VIEW_METADATA option. This way, Access
will
> use view meta data instead of meta data from the underlying base tables.
> See CREATE VIEW in the Books Online for more information.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Ezekil" <ezekil@.lycos.com> wrote in message
> news:411d05d7$0$195$cd19a363@.news.wanadoo.nl...
> > Hello,
> > I need some help with implenting the following:
> > I recently migrated from access to sql server and i now i want to use
> > maintainable permissions on my tables, views, etc. The access database
> will
> > serve as a front-end.
> > I've created for testing purposes an testaccount with only a public role
> to
> > access to my database.
> > Now the hard part is when i want users to select and manipulate the data
> > through views and stored procedures.I want only permissions set on views
> and
> > stored procedures. The reason for this is because i don't want users to
> get
> > the data directly from tables by means of linking or importing them to
> > access
> > or other databases. Only views and stored procedures can be used.
> > Unfortunelately it doesn't work how i wanted to. When i open a view
which
> is
> > linked in access as a table, i'm getting a message that the underlying
> table
> > has not the appropiate permissions.
> > Now there should be a way to apply a maintainable security, so if i
could
> > have some advice and maybe an example on this matter i would be very
> > thankful.|||Here's a simple example:
CREATE TABLE dbo.MyTable
(
Col1 int NOT NULL,
Col2 int NOT NULL
)
GO
CREATE VIEW dbo.MyView
WITH VIEW_METADATA
AS
SELECT Col1
FROM dbo.MyTable
GO
GRANT SELECT ON MyView TO MyRole
GO
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Ezekil" <ezekil@.lycos.com> wrote in message
news:411df325$0$80325$a344fe98@.news.wanadoo.nl...
> Hi Dan,
> I've looked it up in BOL but it is not very clear. Could you provide me
an
> example?
> Thnx
> "Dan Guzman" <danguzman@.nospam-earthlink.net> wrote in message
> news:wxfTc.20463$9Y6.12982@.newsread1.news.pas.eart hlink.net...
> > Try creating the view with the VIEW_METADATA option. This way, Access
> will
> > use view meta data instead of meta data from the underlying base tables.
> > See CREATE VIEW in the Books Online for more information.
> > --
> > Hope this helps.
> > Dan Guzman
> > SQL Server MVP
> > "Ezekil" <ezekil@.lycos.com> wrote in message
> > news:411d05d7$0$195$cd19a363@.news.wanadoo.nl...
> > > Hello,
> > > > I need some help with implenting the following:
> > > > I recently migrated from access to sql server and i now i want to use
> > > maintainable permissions on my tables, views, etc. The access database
> > will
> > > serve as a front-end.
> > > > I've created for testing purposes an testaccount with only a public
role
> > to
> > > access to my database.
> > > > Now the hard part is when i want users to select and manipulate the
data
> > > through views and stored procedures.I want only permissions set on
views
> > and
> > > stored procedures. The reason for this is because i don't want users
to
> > get
> > > the data directly from tables by means of linking or importing them to
> > > access
> > > or other databases. Only views and stored procedures can be used.
> > > > Unfortunelately it doesn't work how i wanted to. When i open a view
> which
> > is
> > > linked in access as a table, i'm getting a message that the underlying
> > table
> > > has not the appropiate permissions.
> > > > Now there should be a way to apply a maintainable security, so if i
> could
> > > have some advice and maybe an example on this matter i would be very
> > > thankful.
> >
We setup a number of roles with access rights to tables in the DB. This week for some unknown reason, rights on these roles disappeared.
We had to run a restore to reset the roles in the database. After the restore, we could not reproduce the problem.
Are there scenarios to avoid that would cause rights to drop from roles and users? (These rights were gone not just hidden)
Tim.
Other than someone dropping the roles and then recreating them, I don't see an accidental way for this to happen. Dropping a role would drop all permissions associated with the role.
Thanks
Laurentiu
|||This happened to me today. Last week I'd setup specific permissions limiting a SQL server account to specific tables/procedures in tempdb. The account is used for maintaining an asp.net application's state. The permissions set are below. Today those permissions were gone. Any idea why?
use tempdb;
go
sp_grantdbaccess MyPeakASPState;
GRANT SELECT on ASPStateTempApplications to MyPeakASPState;
GRANT INSERT on ASPStateTempApplications to MyPeakASPState;
GRANT SELECT on ASPStateTempSessions to MyPeakASPState;
GRANT INSERT on ASPStateTempSessions to MyPeakASPState;
GRANT UPDATE on ASPStateTempSessions to MyPeakASPState;
GO
use aspstate
go
GRANT EXEC ON TempGetStateItem TO MyPeakASPState;
GO
GRANT EXEC ON TempGetStateItem2 TO MyPeakASPState;
GO
GRANT EXEC ON TempGetStateItemExclusive TO MyPeakASPState;
GO
GRANT EXEC ON TempGetStateItemExclusive2 TO MyPeakASPState;
GO
GRANT EXEC ON TempReleaseStateItemExclusive TO MyPeakASPState;
GO
GRANT EXEC ON TempInsertStateItemShort TO MyPeakASPState;
GO
GRANT EXEC ON TempInsertStateItemLong TO MyPeakASPState;
GO
GRANT EXEC ON TempUpdateStateItemShort TO MyPeakASPState;
GO
GRANT EXEC ON TempUpdateStateItemShortNullLong TO MyPeakASPState;
GO
GRANT EXEC ON TempUpdateStateItemLong TO MyPeakASPState;
GO
GRANT EXEC ON TempUpdateStateItemLongNullShort TO MyPeakASPState;
GO
GRANT EXEC ON TempRemoveStateItem TO MyPeakASPState;
GO
GRANT EXEC ON TempResetTimeout TO MyPeakASPState;
GO
GRANT EXEC ON DeleteExpiredSessions TO MyPeakASPState;
GO
GRANT EXEC ON DropTempTables TO MyPeakASPState;
GO
GRANT EXEC ON GetMajorVersion TO MyPeakASPState;
GO
GRANT EXEC ON CreateTempTables TO MyPeakASPState;
GO
GRANT EXEC ON ResetData TO MyPeakASPState;
GO
GRANT EXEC ON TempGetAppID TO MyPeakASPState
|||I wish I could help you. I'm interested that it happened to someone else.
The only advice I can give you - becareful not to change logins when changing security.
My problem may have occurred because I was testing security on a user.
Tim.
|||I think I know what may be happening, please correct me if my assumption is incorrect. The privileges that get lost are the ones related to tempdb, correct?
use tempdb;
go
sp_grantdbaccess MyPeakASPState;
GRANT SELECT on ASPStateTempApplications to MyPeakASPState;
GRANT INSERT on ASPStateTempApplications to MyPeakASPState;
GRANT SELECT on ASPStateTempSessions to MyPeakASPState;
GRANT INSERT on ASPStateTempSessions to MyPeakASPState;
GRANT UPDATE on ASPStateTempSessions to MyPeakASPState;
GO
Tempdb is recreated every time the server is restarted, therefore any information stored there should be consider volatile. Every time SQL Server is restarted all of the permissions listed above will be lost.
I hope this information helps,
-Raul Garcia
SDE/T
SQL Server Engine
|||Thanks, I didn't know that.
We setup a number of roles with access rights to tables in the DB. This week for some unknown reason, rights on these roles disappeared.
We had to run a restore to reset the roles in the database. After the restore, we could not reproduce the problem.
Are there scenarios to avoid that would cause rights to drop from roles and users? (These rights were gone not just hidden)
Tim.
Other than someone dropping the roles and then recreating them, I don't see an accidental way for this to happen. Dropping a role would drop all permissions associated with the role.
Thanks
Laurentiu
|||This happened to me today. Last week I'd setup specific permissions limiting a SQL server account to specific tables/procedures in tempdb. The account is used for maintaining an asp.net application's state. The permissions set are below. Today those permissions were gone. Any idea why?
use tempdb;
go
sp_grantdbaccess MyPeakASPState;
GRANT SELECT on ASPStateTempApplications to MyPeakASPState;
GRANT INSERT on ASPStateTempApplications to MyPeakASPState;
GRANT SELECT on ASPStateTempSessions to MyPeakASPState;
GRANT INSERT on ASPStateTempSessions to MyPeakASPState;
GRANT UPDATE on ASPStateTempSessions to MyPeakASPState;
GO
use aspstate
go
GRANT EXEC ON TempGetStateItem TO MyPeakASPState;
GO
GRANT EXEC ON TempGetStateItem2 TO MyPeakASPState;
GO
GRANT EXEC ON TempGetStateItemExclusive TO MyPeakASPState;
GO
GRANT EXEC ON TempGetStateItemExclusive2 TO MyPeakASPState;
GO
GRANT EXEC ON TempReleaseStateItemExclusive TO MyPeakASPState;
GO
GRANT EXEC ON TempInsertStateItemShort TO MyPeakASPState;
GO
GRANT EXEC ON TempInsertStateItemLong TO MyPeakASPState;
GO
GRANT EXEC ON TempUpdateStateItemShort TO MyPeakASPState;
GO
GRANT EXEC ON TempUpdateStateItemShortNullLong TO MyPeakASPState;
GO
GRANT EXEC ON TempUpdateStateItemLong TO MyPeakASPState;
GO
GRANT EXEC ON TempUpdateStateItemLongNullShort TO MyPeakASPState;
GO
GRANT EXEC ON TempRemoveStateItem TO MyPeakASPState;
GO
GRANT EXEC ON TempResetTimeout TO MyPeakASPState;
GO
GRANT EXEC ON DeleteExpiredSessions TO MyPeakASPState;
GO
GRANT EXEC ON DropTempTables TO MyPeakASPState;
GO
GRANT EXEC ON GetMajorVersion TO MyPeakASPState;
GO
GRANT EXEC ON CreateTempTables TO MyPeakASPState;
GO
GRANT EXEC ON ResetData TO MyPeakASPState;
GO
GRANT EXEC ON TempGetAppID TO MyPeakASPState
|||I wish I could help you. I'm interested that it happened to someone else.
The only advice I can give you - becareful not to change logins when changing security.
My problem may have occurred because I was testing security on a user.
Tim.
|||I think I know what may be happening, please correct me if my assumption is incorrect. The privileges that get lost are the ones related to tempdb, correct?
use tempdb;
go
sp_grantdbaccess MyPeakASPState;
GRANT SELECT on ASPStateTempApplications to MyPeakASPState;
GRANT INSERT on ASPStateTempApplications to MyPeakASPState;
GRANT SELECT on ASPStateTempSessions to MyPeakASPState;
GRANT INSERT on ASPStateTempSessions to MyPeakASPState;
GRANT UPDATE on ASPStateTempSessions to MyPeakASPState;
GO
Tempdb is recreated every time the server is restarted, therefore any information stored there should be consider volatile. Every time SQL Server is restarted all of the permissions listed above will be lost.
I hope this information helps,
-Raul Garcia
SDE/T
SQL Server Engine
|||Thanks, I didn't know that.
We setup a number of roles with access rights to tables in the DB. This week for some unknown reason, rights on these roles disappeared.
We had to run a restore to reset the roles in the database. After the restore, we could not reproduce the problem.
Are there scenarios to avoid that would cause rights to drop from roles and users? (These rights were gone not just hidden)
Tim.
Other than someone dropping the roles and then recreating them, I don't see an accidental way for this to happen. Dropping a role would drop all permissions associated with the role.
Thanks
Laurentiu
|||This happened to me today. Last week I'd setup specific permissions limiting a SQL server account to specific tables/procedures in tempdb. The account is used for maintaining an asp.net application's state. The permissions set are below. Today those permissions were gone. Any idea why?
use tempdb;
go
sp_grantdbaccess MyPeakASPState;
GRANT SELECT on ASPStateTempApplications to MyPeakASPState;
GRANT INSERT on ASPStateTempApplications to MyPeakASPState;
GRANT SELECT on ASPStateTempSessions to MyPeakASPState;
GRANT INSERT on ASPStateTempSessions to MyPeakASPState;
GRANT UPDATE on ASPStateTempSessions to MyPeakASPState;
GO
use aspstate
go
GRANT EXEC ON TempGetStateItem TO MyPeakASPState;
GO
GRANT EXEC ON TempGetStateItem2 TO MyPeakASPState;
GO
GRANT EXEC ON TempGetStateItemExclusive TO MyPeakASPState;
GO
GRANT EXEC ON TempGetStateItemExclusive2 TO MyPeakASPState;
GO
GRANT EXEC ON TempReleaseStateItemExclusive TO MyPeakASPState;
GO
GRANT EXEC ON TempInsertStateItemShort TO MyPeakASPState;
GO
GRANT EXEC ON TempInsertStateItemLong TO MyPeakASPState;
GO
GRANT EXEC ON TempUpdateStateItemShort TO MyPeakASPState;
GO
GRANT EXEC ON TempUpdateStateItemShortNullLong TO MyPeakASPState;
GO
GRANT EXEC ON TempUpdateStateItemLong TO MyPeakASPState;
GO
GRANT EXEC ON TempUpdateStateItemLongNullShort TO MyPeakASPState;
GO
GRANT EXEC ON TempRemoveStateItem TO MyPeakASPState;
GO
GRANT EXEC ON TempResetTimeout TO MyPeakASPState;
GO
GRANT EXEC ON DeleteExpiredSessions TO MyPeakASPState;
GO
GRANT EXEC ON DropTempTables TO MyPeakASPState;
GO
GRANT EXEC ON GetMajorVersion TO MyPeakASPState;
GO
GRANT EXEC ON CreateTempTables TO MyPeakASPState;
GO
GRANT EXEC ON ResetData TO MyPeakASPState;
GO
GRANT EXEC ON TempGetAppID TO MyPeakASPState
|||I wish I could help you. I'm interested that it happened to someone else.
The only advice I can give you - becareful not to change logins when changing security.
My problem may have occurred because I was testing security on a user.
Tim.
|||I think I know what may be happening, please correct me if my assumption is incorrect. The privileges that get lost are the ones related to tempdb, correct?
use tempdb;
go
sp_grantdbaccess MyPeakASPState;
GRANT SELECT on ASPStateTempApplications to MyPeakASPState;
GRANT INSERT on ASPStateTempApplications to MyPeakASPState;
GRANT SELECT on ASPStateTempSessions to MyPeakASPState;
GRANT INSERT on ASPStateTempSessions to MyPeakASPState;
GRANT UPDATE on ASPStateTempSessions to MyPeakASPState;
GO
Tempdb is recreated every time the server is restarted, therefore any information stored there should be consider volatile. Every time SQL Server is restarted all of the permissions listed above will be lost.
I hope this information helps,
-Raul Garcia
SDE/T
SQL Server Engine
|||Thanks, I didn't know that.
sql