CA2122 DoNotIndirectExposeMethodsWithLinkDemands

Question

I got error CA2122 DoNotIndirectlyExposeMethodsWithLinkDemands on this function :

  internal static string GetProcessID()
        {

                return Process.GetCurrentProcess().Id.ToString(CultureInfo.CurrentCulture);

        }

How to fix it?

Answer 1

I got error CA2122

It is not an error, just a warning. The code analysis tool you are using checks for lots of obscure corner-cases, the kind that the C# compiler does not complain about but might be a bad practice. And the kind that programmers are often unaware of. It was originally designed as an internal tool used by Microsoft programmers working on framework code. The rules they must follow are pretty draconian since they can't predict how their code is going to be used.

...WithLinkDemands

A link demand is Code Access Security (CAS) detail. It ensures that code has sufficient rights to execute. Link demands are very cheap, they are checked only once, happens when the code is just-in-time compiled. The "only-once" clause is what the warning is talking about, it is technically possible for code that has sufficient rights to execute first, thus allowing the method to be jitted, but used later by non-trusted code, thus bypassing the check. The tool just assumes that this might happen because the method is public, it doesn't know for a fact that this actually happens in your program.

return Process.GetCurrentProcess()...

It is the Process class that has the link demand. You can tell from the MSDN article which demands it makes. It verifies that the calling code runs in full trust, that it doesn't run in a restrictive unmanaged host like SQL Server and that a derived class meets these demands as well. The Process class is a bit risky, untrusted code could do naughty things by starting a process to bypass CAS checks or to learn too much about the process it runs in and tinker with its configuration.

How to fix it?

More than one possible approach. Roughly in order:

1. Always high odds that this warning just doesn't apply to your program. In other words, there is no risk of it ever executing code that you don't trust. Your program would have to support plug-ins, written by programmers you don't know about but still have access to the machine to tell your program to load their plug-in. Not very common. Proper approach then is to configure the tool to match your program's behavior, you'd disable the rule.

2. Evaluate the risk of untrusted code using this method. That ought to be a low one for this specific method, exposing the process ID does not give away any major secrets. It is just a number, it doesn't get to be a risky number until it is used by code that uses Process.GetProcessById(). So you'd consider to suppress the warning, apply the [SuppressMessage] attribute to the method. This is a common outcome, the framework source code has lots and lots of them.

3. Follow the tool's advice and apply the CAS attributes to this method as well. Simply a copy-paste from the link demands you saw in the MSDN article. This closes the "only-once" loophole, the untrusted code will now fail to jit and can't execute.