NOONE ASKED FOR THIS!!! why the heck is BACKUP CERTIFICATE altering the file's ACLs - it's just a PUBLIC CERT I'm exporting!!
in additions MS doesn't seem able to add the ability to re-inherit file-rights from parent objects via the command-shell.
I export the public-key for a reason! I want to import it on another machine (automatically) to establish a trust. But this freaking "feature" is costing me HOURS of research on how to get rid of these ACLs on a public certificate!!!
argh!!!
sorry, I really had to get this out!
why not at least give us a switch we can set in BACKUP CERTIFICATE command to stop this from happening?
is there a work-around? now I need to activate
EXEC sp_configure 'show advanced options', 1
and
EXEC sp_configure 'xp_cmdshell', 1
just to be able to issue a (not working) DOS command cacls... to try to fix the "feature".
there's got to be a better way!!!
also - why can't there be a switch to force overwriting the target file, if it already exists? It's a BIG PAIN having to do lots of other stuff, just to be able to "backup" the certificate!
You gave us "xp_FileExist", but no xp_FileDelete with similar parameters!! again, I need to issue DOS COMMANDS just to do stuff I would not have to if someone at the levers was actually activating the back-brain!
PLEASE give me some hints on how MS recommends to solve these features!
Hello -
First, you probably really don't want a lot of OS features in a database. Every one of them represents an extreme security risk. The ability to delete files from SQL Server would be a very dangerous thing, while checking to see if a file is present is less of a danger. There are always tradeoffs.
Second, the ACLs are there for protection, not to make things harder. We aren't trying to make things difficult. We do, however, want to hear your concerns - here's a good place for you to voice your wish-list:
http://connect.microsoft.com/SQLServer
Also, you can perform OS operations more safely in a CLR procedure than turning on xp_cmdshell. This article talks a little about the CLR and file ops:
http://aspalliance.com/1081_CLR_Integration_in_SQL_Server_2005
|||
then why supply xp_File* in the first place?
what's the point in securing a public certificate? would it not be reasonable to at least be able to turn that "feature" off by switch? even the private-key is secured by PWD and IIS, or the Certificate-MMC-SnapIn, for instance, leave the ACLs alone as they do assume anyone doing stuff like that knows what he's doing. This goes more so for any DBA exporting certs, as it's not that easy without reading some docs.
but thanks for your input!
I will try some more - maybe I can disable rights-changing on the network-share to get SQL to stop messing around with my ACLs.
|||The file sp's are there to help - and hopefully the least dangerous ones are all you need to do in a database. I'd recommend doing any other file operations (including the ACL work) in CLR's.
I agree that it would be great to have docs around this. In fact, we change the docs all the time, and add "use cases" that deal with this kind of thing. Again, thanks for using our stuff. We want you to be able to do your job quickly and easily. Go to that site I referenced and sound off! The developers acutally read what you put there and code the product around the features that get the most noise. Not many other software companies work like that, believe me.
|||Buck Woody - MSFT wrote:
First, you probably really don't want a lot of OS features in a database. Every one of them represents an extreme security risk.
one last note on that: I wouldn't have to, if SQL wouldn't mess-up (or mess around) with the ACLs and if SQL would let me overwrite a certificate. Instead it chooses to be smart and not let me turn off this smartness...
|||Point taken. Seems there are a couple of ways to handle this - please be sure and visit the link I mentioned so that the developers will get your requests!
No comments:
Post a Comment