cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [ACS401] Blocker Bugs for 4.0.1
Date Thu, 29 Nov 2012 20:23:12 GMT
Rohit,

Thanks...  I'll do some debugging to make sure I get it covered off
correctly.  However, the change I did should have eliminated the
response object from being appended to the auditTrailSb for the
command in question.  Unless I'm reading the code incorrectly (which I
might be), the fact that the actual logger call happens in the
ApiServlet class shouldn't matter.

Good to know about the api_refactoring part...  and I do agree that
pulling sensitive data out in a clean way would be better than the
simple if/else logic I added.

On Thu, Nov 29, 2012 at 3:13 PM, Rohit Yadav <rohit.yadav@citrix.com> wrote:
> Committed on 4.0, 515. For 505, I'm not sure fix by Chip will work as logging into api.log
happens by the servlet (APIServlet) some fix like this should work:
>
> diff --git a/server/src/com/cloud/api/ApiServlet.java b/server/src/com/cloud/api/ApiServlet.java
> index 8a1d4de..3ab6497 100755
> --- a/server/src/com/cloud/api/ApiServlet.java
> +++ b/server/src/com/cloud/api/ApiServlet.java
> @@ -103,6 +103,13 @@ public class ApiServlet extends HttpServlet {
>          }
>      }
>
> +    /*
> +     * Strips off sensitive content based on
> +     */
> +    private String stripSensitiveContent(String str) {
> +
> +    }
> +
>      @SuppressWarnings("unchecked")
>      private void processRequest(HttpServletRequest req, HttpServletResponse resp) {
>          StringBuffer auditTrailSb = new StringBuffer();
> @@ -334,7 +341,7 @@ public class ApiServlet extends HttpServlet {
>                  auditTrailSb.append(" unknown exception writing api response");
>              }
>          } finally {
> -            s_accessLogger.info(auditTrailSb.toString());
> +            s_accessLogger.info(stripSensitiveContent(auditTrailSb.toString()));
>              // cleanup user context to prevent from being peeked in other request context
>              UserContext.unregisterContext();
>          }
>
> Some work on refactoring the api layer is going on api_refactoring, the goal is to separate
policy from mechanism and separate tightly coupled security checks using annotations, and
also fix and automate docs. Because this the APIServlet.java will have a function, one point
to strip out sensitive data like passwords and ssh-keys from logs instead of not logging them
completely. I'll start another thread on api_refactoring and this issue.
>
> Regards.
>
> On 29-Nov-2012, at 9:34 AM, Chip Childers <chip.childers@sungard.com> wrote:
>
>> On Wed, Nov 28, 2012 at 7:41 PM, Joe Brockmeier <jzb@zonker.net> wrote:
>>> On Thu, Nov 29, 2012 at 11:56:39AM -0500, Chip Childers wrote:
>>>> I'll look at 505.
>>>
>>> Great, thanks!
>>
>> Fix committed to master and 4.0 branches (from the air no-less) ;-)
>>
>> -chip
>
>

Mime
View raw message