lkml.org 
[lkml]   [2002]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] ext2 and ext3 block reservations can be bypassed
I.e. a fix to ext2/ext3 is not horribly useful.

mark


On Tue, May 14, 2002 at 01:54:40PM -0500, Jesse Pollard wrote:
> --------- Received message begins Here ---------
>
> >
> > Don't put /var/log on the same file system as /home, and don't grant
> > access to /var/log to any normal userid.
> >
> > This isn't 'new'.
>
> Also not relevent. If you want to get picky, don't put root, /usr, /var
> and /etc on the same filesystem. Make them all separate. Don't put
> /tmp, /var/tmp, on the same filesystem either. Mount /usr read only.
> mount / read only, mount all user writable filesystems nosetuid, nosetgid.
>
> However, not all daemons run as root, but do log into /var/adm or /var/log.
> If these fill up the log device without restraint, then your audit logs will
> ALSO be affected (unless you have syslog send them to a different host).
>
> Users don't have to have access to the filesystem to cause write activity
> to it. The reserved space is just a small thing. It can't catch everything,
> but the system CAN continue to function after the filesystem fills up.
> Hopefully, long enough to record events and allow the administrator to
> clean up. That is the ONLY security function it has.
>
> > mark
> >
> >
> > On Tue, May 14, 2002 at 12:53:47PM -0500, Jesse Pollard wrote:
> > > If the root file system is ext2, it does become a security issue since
> > > currently active logs will continue to record log entries until the
> > > filesystem is absolutly filled. I should say, if the log device fills up,
> > > since the log directory is usually /var/log, or /var/adm. Some logs show
> > > up in etc, but that really depends on the configuration. It IS usefull if the
> > > filesystem is "full" due to attacks - daemons tend to terminate themselves,
> > > and their log entry indicates what the problem was. If it is an attack, then
> > > it's a security issue.
> > >
> > > The only reason it helps fragmentation (subject to actual implementor
> > > statements) is that the filesystem code will use every scavanged block
> > > possible under saturation. When the filesystem gets cleand up later,
> > > these excessively fragmented files will remain, and continue to cause
> > > access delays.
> > >
> > > Naturally, deleting (or backup/restore) the file(s) cleans up the fragmentation.
> > >
>
> -------------------------------------------------------------------------
> Jesse I Pollard, II
> Email: pollard@navo.hpc.mil
>
> Any opinions expressed are solely my own.

--
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:26    [W:0.033 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site