cvs commit: src/etc/periodic/security 100.chksetuid
Giorgos Keramidas
keramida at ceid.upatras.gr
Thu Jan 13 11:08:03 PST 2005
On 2005-01-13 18:53, Ceri Davies <ceri at submonkey.net> wrote:
>On Thu, Jan 13, 2005 at 10:49:14AM -0800, Don Lewis wrote:
>>On 13 Jan, Ceri Davies wrote:
>>>On Thu, Jan 13, 2005 at 06:28:26PM +0300, Gleb Smirnoff wrote:
>>>>On Thu, Jan 13, 2005 at 03:24:30PM +0000, Ceri Davies wrote:
>>>>> Umm, why not? If setuid binaries appear anywhere on my system then I'd
>>>>> like to continue to be told so that I can be confident of where they
>>>>> came from. I don't care if they pose an immediate threat or not.
>>>>
>>>> In this case "grep -v nosuid" must be removed, too, to be consistent.
>>>>
>>>> P.S. We have "grep -v nosuid" from the very beginning.
>>>
>>> Hmm. I retract my objection then, whilst retaining my reservations.
>>
>> I did something like this locally way back in the 2.1.x days. Running
>> suid checks on the news spool, the squid cache, the CD-ROM changer
>> (causing it to sometimes lock up), and a bunch of NFS clients
>> simultaneously doing suid checks on the same NFS server got to be a
>> drag.
>
> Sounds like something like chksetuid_exclude which lists mountpoints to
> exclude might be in order. Any objections to me putting that together,
> or are people happy with the status quo?
It's not a bad idea. While you're at it, a knob that disables checks
for NFS-mounted filesystems may be nice too. It doesn't make sense to
check the same files both in the client *and* the server, as Don has
pointed out.
I think I can almost see this coming :-)
daily_status_security_chksetuid_nfs="NO"
- Giorgos
More information about the cvs-src
mailing list