Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Installing to GAC.

  Asked By: Katharine    Date: Feb 17    Category: Sharepoint    Views: 1972

Best practice says, "Don't install to the GAC." Is there ever a time a developer
would be allowed to do this? We have a customer that has contracted with an
outside developer to build their custom SP application and they want to install
to our GAC. Anyone care to chime in with their thoughts beyond that you should
not do that? I'd appreciate the feedback.

Share: 

 

12 Answers Found

 
Answer #1    Answered By: David Small     Answered On: Feb 17

In certain circumstances installing  to the GAC is your only choice. For
example, event receivers can't be installed anywhere except the GAC. Having
said that there are normally two reasons developers want to install  to the
GAC instead of the bin directory of the Web Application. The first is a
reasonable reason in my opinion. The second is not. Just make sure that if
you prohibit them from installing into the GAC that you don't set Trust
Level = "Full" as an alternative to properly setting Code Access Security
(CAS). Here are the two reasons.



1) The managed code assembly will be used by more than one Web
Application. If the assembly will be used by all the Web Applications in
the Farm its not efficient to install the assembly into every local bin
directory. Code installed in the GAC can be used by every Web App. (This
is reasonable)

2) The developer  doesn't want to or can't write the appropriate CAS
policy statements. Since code in the GAC is always fully trusted you don't
need to do a CAS policy for GAC deployed code. This is either a case of
being lazy or lacking knowledge. Neither is something I would want in a
developer I hired. Code should always run with the least set of privileges
required in CAS unless it is shared code as described in #1.



By the way, #2 is quite common in the development industry. But that
doesn't mean its right.

 
Answer #2    Answered By: Troy Tucker     Answered On: Feb 17

Now I wished I had taken your developer's
class too so I would know much of this already.

 
Answer #3    Answered By: Monica Bailey     Answered On: Feb 17

No problem. As you can tell, the topic hit on one of the things I'm fairly
outspoken about. But this group is all about good discussion and learning.
So if that happened it was time  well spent.

 
Answer #4    Answered By: Chandra Manjrekar     Answered On: Feb 17

And that's why you get paid the BIG bucks! Thank you Paul! I will take this to
my team here and start looking at minimizing our deployments to the GAC.
Thankfully none of our work goes external so the attack surface is minimized,
for now.

 
Answer #5    Answered By: Lora Wall     Answered On: Feb 17

And, if I may add to that:

Does the behaviour of a SP solution change when you target the App Pool as
opposed to the GAC? We deploy EVERYTHING to the GAC. What's the big deal and how
should we be doing things differently?

 
Answer #6    Answered By: Mahendra Parte     Answered On: Feb 17

The main change in behavior is two things.



1. Code deployed to the GAC is fully trusted. That means it can do
anything on the server. If someone hacks the assembly in the GAC they can
do anything. Code deployed to the bin is only allowed  to do what its CAS
policy specifies. If the CAS policy specifies "Full Trust" then there is no
difference. But a developer  should be writing the CAS policy to only allow
the code to have the fewest privileges required to do the job. Even if the
code gets hacked it can't do what CAS won't let it.

2. Code deployed to the GAC is available to every application  pool on
the server. It still loads and runs in a specific app pool, so if you have
lots of app pools it will load several times. Code in the bin can only run
in the app pool associated with that web application. To run it in a second
web app it must be re-deployed.



When a solution targets a specific web app it deploys the code to that bin
directory only. If you target multiple web apps, it will re-depoly the code
to each web app. Code deployed to the GAC only deploys once.

 
Answer #7    Answered By: Sue Alford     Answered On: Feb 17

I'm a little confused. "If the code gets hacked", doesn't the malicious
party already have power to mess up the whole system? I'm pretty sure if
they're already changing code in the GAC, you're not going to stop them from
doing much else.

 
Answer #8    Answered By: Devon Welch     Answered On: Feb 17

Ok, then let's just say if the code has a BUG. The bottom line is code in
the GAC can do anything, code in the bin can only do what CAS allows. It is
a security Best Practice to always employee "least privilege". After all,
you wouldn't make all your user's Farm administrators would you? Why should
you give that kind of power to every piece of code. Writing CAS policies is
more work, but it is the "Right" way to do it from a Security Best Practices
approach.

 
Answer #9    Answered By: Sridhar Tantry     Answered On: Feb 17

For more info, read the following article:

store.bamboosolutions.com/kb/article.aspx?id=10405

 
Answer #10    Answered By: Jonathan Justice     Answered On: Feb 17

For the record, I'm not a GAC man; just wanted to make sure
I hadn't missed part of the rationale here.

 
Answer #11    Answered By: Dhanishta Bapakar     Answered On: Feb 17

Here is another reason why GAC deployment is sometimes unavoidable:
calling web services that require access to a certificate. I've tried
in WCF and with WSE2 to call services that required signed or XML
encrypted messages, requiring access to the local certificate store
and the private key file of a cert. This just isn't possible using
CAS. There's no option or field that can be specified as such. GAC
deployment is the only option.

I'm not really convinced that this is a problem per say, as the
private key is protected from non trusted deployments, but it can be
annoying.

 
Answer #12    Answered By: Easy Tutor     Answered On: Feb 17

As I mentioned in the original reply there are times when a GAC deployment
is unavoidable. Web Services is another instance of that.

 
Didn't find what you were looking for? Find more on Installing to GAC. Or get search suggestion and latest updates.




Tagged: