Hi, I would use the code from get_runlevel_sysv(), re-factor the common parts to avoid repeating code and implement only the SUSE-specific final check.
I wouldn't use chkconfig, because RHEL part doesn't use it so I would like to avoid a platform specific solution if it isn't really necessary. Best Regards Jan Černý Security Technologies | Red Hat, Inc. ----- Original Message ----- > From: "S, Gautam" <gaut...@hpe.com> > To: "Jan Cerny" <jce...@redhat.com> > Cc: open-scap-list@redhat.com > Sent: Tuesday, March 22, 2016 5:40:00 AM > Subject: RE: [Open-scap] Run-level probes on SUSE > > 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:jce...@redhat.com] > Sent: Monday, March 21, 2016 1:40 PM > To: S, Gautam <gaut...@hpe.com> > Cc: open-scap-list@redhat.com > 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" <gaut...@hpe.com> > > To: open-scap-list@redhat.com > > 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 > > Open-scap-list@redhat.com > > https://www.redhat.com/mailman/listinfo/open-scap-list > _______________________________________________ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
