Re: [RFC] Purging dead modules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Chris PeBenito <pebenito@xxxxxxxx> writes:

> On 1/11/21 6:52 PM, Topi Miettinen wrote:
>> On 11.1.2021 17.48, Russell Coker wrote:
>>> On Tuesday, 12 January 2021 2:23:47 AM AEDT Dominick Grift wrote:
>>>>> I'm looking to remove modules for dead programs, such as hal and
>>>>> consolekit. The question is how long to keep modules for dead
>>>>> programs?  I'm thinking something like 3-5 years.
>>>>
>>>> Agree
>>>
>>> I think we should drop them when the programs aren't in the latest DEVELOPMENT
>>> versions of Fedora, Debian, or any other distribution that supports SE Linux.
>> I think this could be automated. If no file contexts in a module
>> match any files in a list of all files of all packages of the
>> selected distros concatenated, the module is probably obsolete
>> (which could be also verified by looking at old releases) or it's
>> for 3rd party software (never found in earlier distro releases). I
>> tried to do this locally to disable unused modules, but it took way
>> too long time with shell scripts. I suppose with a database or other
>> proper tools it would be trivial.
>
> This is a good idea, but may be a problem for the Gentoo guys.
>
> I'd probably simplify it to only looking at labels for executables,
> since a package's manifest might not hit all of the data files'
> entries.

Not sure if it is worth the trouble to automate this. The list of candidates I came up with
were also verified by just using `dnf whatprovides /usr/bin/app` to see
if it returns. Most modules though are still relevant and it's is pretty
obvious that they are still relevant. So I would argue that spending
half an hour perusing the refpolicy and looking for candidates, then
verifying is enough to atleast identify the most obvious candidates for
removal.

In reply to Russell Coker and kerneloops: Does kerneloops not depend on
kerneloops.org? AFAIK that site is offline so not sure how Debian still
expects kerneloops to still work?

-- 
gpg --locate-keys dominick.grift@xxxxxxxxxxx
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux