Hello Jan, I had a query regarding the implementation of the probe. Currently I am reusing the code from the function "get_runlevel_sysv()" because apart from the final check, the rest of it remains the same on SUSE currently. Is this the right way to go about it? Or should I use something like say the chkconfig utility within the probe on SUSE so that the result is reliable even if the run-level implementation is changed later?
Thank you. Regards, Gautam. -----Original Message----- From: Jan Cerny [mailto:[email protected]] Sent: Monday, March 21, 2016 1:40 PM To: S, Gautam <[email protected]> Cc: [email protected] Subject: Re: [Open-scap] Run-level probes on SUSE Hello, This sounds good to me. We are looking forward to your patches. Best regards Jan Černý Security Technologies | Red Hat, Inc. ----- Original Message ----- > From: "S, Gautam" <[email protected]> > To: [email protected] > Sent: Friday, March 18, 2016 6:52:54 PM > Subject: [Open-scap] Run-level probes on SUSE > > > > Hello, > > > > This is an investigation into an issue I had reported under title > “Make check errors on SUSE”. Šimon Lukašík has suggested that openscap > would be interested in accepting a patch for this problem. > > > > The run-level probe tests on SUSE were failing as the OVAL definition > evaluation returns error. A quick check into the code shows that the > probe is not implemented for SUSE platform. > https://github.com/OpenSCAP/openscap/blob/maint-1.2/src/OVAL/probes/un > ix/runlevel.c#L237 > > > > static int get_runlevel_suse (struct runlevel_req *req, struct > runlevel_rep > **rep) > > { > > return (-1); > > } > > > > From what I understand, the way init works on SUSE is slightly > different from the sysV init model used on RHEL. On RHEL, the probe > checks and finds a symbolic link of the init.d/<service> script in the > rc<>.d/ directory. Based on whether that file starts with a ‘K’ or an > ‘S’, the service state for that run level is determined as either > disabled or enabled. Because of the optimizations in SUSE, on > run-levels where the service is disabled, there won’t be a symbolic > link to the init.d/<service> script and on run-levels where the > service is enabled, both K and S script will be found. I do not know > if this is a foolproof logic to determine the service states on SUSE > but it does seem to work both with the tests in make check as well as > other independent service based definitions. There is still a minor > issue in the test case itself in the get_services_list() module but this has > nothing to do with oscap, all valid service level definitions get evaluated > correctly. > > > > I can send the code for review if this looks alright. > > > > Thank you. > > > > Regards, > > Gautam. > > _______________________________________________ > Open-scap-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/open-scap-list _______________________________________________ Open-scap-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/open-scap-list
