Date: Sat, 16 Mar 2002 15:58:41 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: "Rogier R. Mulhuijzen" <drwilco@drwilco.net> Cc: Jeff Jirsa <jjirsa@hmc.edu>, freebsd-hackers@FreeBSD.ORG, arr@FreeBSD.ORG Subject: Re: logging securelevel violations Message-ID: <Pine.NEB.3.96L.1020316155309.32957A-100000@fledge.watson.org> In-Reply-To: <5.1.0.14.0.20020316204406.01c3bcb0@mail.drwilco.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 16 Mar 2002, Rogier R. Mulhuijzen wrote: > At 09:23 16-3-2002 -0500, Robert Watson wrote: > > Second, these > >warnings would be generated during normal operations, as a number of > >applications attempt to load kernel modules when they need them, including > >ppp. Generating spurious warnings as part of normal system activity isn't > >necessarily a useful activity, and tends to result in more calls for help > >on questions@. > > I don't know. Today I had someone who had trouble installing a new > kernel. I asked him what secure level he used and he didn't know. > Turned out he had selected the SECURE profile in the installer and had > securelevel 2. If the kernel had spewed a message at him saying > something like "Cannot remove file with current securelevel" or likewise > he would have been able to figure it out on his own. Arguably, we shouldn't be exposing securelevels to users who might turn them on by accident, since the model doesn't actually provide much if any protection in the default shipped configuration. > When you try to write to a file and normal file permissions deny you > this action don't you get a "permission denied"? It's just an error > message informing the user something can't be done because of a specific > reason. The permission denied message on writing to a file isn't because of securelevels, it's because of the file flags on the file. The only effect of securelevels on the UFS implementation is in the file flag change call, where change requests are denied based on securelevels. Probably, if a file flag is set and the install program can't remove it, it should print that the file flag can't be removed, possibly due to securelevels. > If a user can't load kernel modules that he needs for ppp, wouldn't you > rather have him ask "I get this message about securelevel when I try to > use ppp and it doesn't work" instead of "ppp doesn't work and I don't > know why"? If the userland application gets back EPERM from an attempt to load a kernel module, it should either work around the failure as appropriate, or print an appropriate error message to the user regarding the failure. Note that not all module loading is fatal for the application, and so it may not be a failure condition for the application. Under those circumstances, printing a kernel message would not be helpful. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020316155309.32957A-100000>