[¤1] Pegasus Enhancement Proposal (PEP)

[¤2] PEP #: 312

[¤3] PEP Type: Functional

[¤4] Title: Separate OOP logs

[¤5] Version: 0.2

[¤6] Created: 18th December 2007

[¤7] Authors: Ouyang Jian

[¤8] Status: draft

[¤9]  

[¤10] Version History:

[¤27]  

[¤28] Abstract: Make OOP providers write their own log files.

[¤29] Definition of the Problem

[¤30] Currently log files are set to 600 mode to prevent from been removed or fabricated by non-superusers. But when OOP providers switch to non-superuser user context (registered with DesignatedUserContext), they no longer be able to write the log files again (lost).

[¤31] Users of a provider very likely to be interested in only it's agent's log. It is hard for them to strip them out from a hash file.

[¤32] Proposed Solution

[¤33] Make OOP providers write their own log files. (just like what trace file does now)

[¤34] We just need to mutex between threads in a single provider, no need to mutex between processes.

[¤35] OOP provider agent create their own log files, so the file authority problem is no longer there.

[¤36] Finally a provider user can simply get all log of his provider from it's log file, no need to filter other uninterested log, and user can remove his log freely.

[¤37] I suggest the log file name of OOP provider to be in the from of "<log name>.<module name>.<user name>.log". For example: ProviderAgentStandard.testmodule.ouyang.log.

[¤38] Rationale

[¤39] Separate single log file into log files owned by OOP processes to eliminate file authority problem.

[¤40] Provider users need not look through all the unwanted logs.

[¤41] Design

[¤42] 1) When logdir is firstly created, set it's permission to 755.

[¤43] 2) Before OOP provider is forked cimserver create log files for agent, change file authority to 600, and change file owner to the user who runs the agent.

[¤44] 3) When OOP provider agent begins, it resets log file names in LoggerRep. So all it's log will be written in its own log files

[¤45] 4) No need to use file lock to mutex between processes any more.

[¤46] Build option

[¤47] Add a macro 'PEGASUS_SEPARATE_OOP_LOG' to enable this function. Defaultly it is not defined.

[¤48] Implementation prototype

[¤49] Source files need to be changed

[¤50] Common/Logger.cpp

[¤51] Common/Logger.h

[¤52] ProviderManagerService/OOPProviderManagerRouter.cpp

[¤53] ProviderManagerService/ProviderAgent/ProviderAgent.cpp

[¤54] ProviderManagerService/ProviderAgent/cimprovagt.cpp

[¤55] Impacted modules

[¤56] libpegcommon.so

[¤57] libpegpmservice.so

[¤58] cimprovagt

[¤59] A prototype patch looks like:

[¤345] Result of prototype

[¤346] We try the same test on prototype implementation. Here is the result:

[¤347] a) Set logLevel to INFORMATION, CIM Server did not have other work. A provider agent continuously wrote 200000 log entries, cost about 1453 clocks. While two provider agents wrote 100000 at same time cost about 1070 and 11012 clocks separately. This shows their response time got improved.

[¤348] b) Set logLevel to TRACE, a client repeatedly send "cimcli nc -n root/cimv2; cimconfig -g forceProcesses;". A provider agent continuously wrote 100000 log entries, cost about 1261 clocks. While two provider agents wrote 50000 at same time cost about 733 and 753 clocks separately.

[¤349] Schedule

[¤390] Discussion

[¤391]

[¤392] (r_kumpf) World writable directories are a source of security vulnerabilties. Careful attention is needed to protect such a directory from attack. Using the sticky bit is a good start. In cases where the names of the files that will be created are predictable (such as in this proposal), an attacker could create the file an advance with a different owner. That 'unauthorized' owner would be able to read the data that is subsequently written to the file. Or, an attacker could create a symbolic link to cause the data to be written in an unexpected (and harmful) place. It is best to avoid world-writable directories at all, if possible. Enabling writes to this directory by default heightens the concern.

[¤396]
[¤397] Copyright (c) 2006 Hewlett-Packard Development Company, L.P.; IBM Corp.;
[¤398] EMC Corporation; Symantec Corporation; The Open Group.
[¤399]
[¤400] Permission is hereby granted, free of charge, to any person obtaining a copy
[¤401] of this software and associated documentation files (the "Software"), to
[¤402] deal in the Software without restriction, including without limitation the
[¤403] rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
[¤404] sell copies of the Software, and to permit persons to whom the Software is
[¤405] furnished to do so, subject to the following conditions:
[¤406]
[¤407] THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL BE INCLUDED IN
[¤408] ALL COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE SOFTWARE IS PROVIDED
[¤409] "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
[¤410] LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
[¤411] PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
[¤412] HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
[¤413] ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
[¤414] WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

[¤415]  

[¤416] Template last modified: March 26th 2006 by Martin Kirk
[¤417] Template version: 1.11