[1021] in linux-security and linux-alert archive

home help back first fref pref prev next nref lref last post

Re: [linux-security] Re: Possible bufferoverflow condition in lpr, xterm and xload

daemon@ATHENA.MIT.EDU (Ralf Schlatterbeck)
Mon Aug 19 19:45:47 1996

From: ralf@zoo.priv.at (Ralf Schlatterbeck)
To: linux-security@tarsier.cv.nrao.edu
Date: Mon, 19 Aug 1996 21:00:04 +0200 (MET DST)
In-Reply-To: <199608132017.QAA01216@tarsier.cv.nrao.edu> from "Jeff Uphoff" at Aug 13, 96 04:17:16 pm

Jeff Uphoff writes:

> I wrote a patch, sometime in '93, that tracked what user mounted such an
> FS and only allowed that user--or root, of course--to unmount said
> filesystem.  I never submitted this patch to the util. maintainers (I
> used it extensively locally, however), but since it looks like
> mount/umount are about to get a bit of a rewrite perhaps I should update
> it and submit it....

Good Idea, maybe we could get rid of some other (optionally) suid
binaries associated with samba and Netware filesystems, i.e., ncpumount.
(I don`t know if there is also a smbumount). Maybe these could be
integrated into umount? The only reason these (this?) exist is to
guarantee users can umount the filesystems they mounted (if I understood
the documentation).

[REW: I take an s-bit on a binary to mean that the application was
developed with that s-bit in mind. Tacking an s-bit on an application
that doesn't expect it is suicide. It should therefore be a no-no.

Maybe installation notes could mention "if you want you can remove the
s-bit from this and that application", but I find the idea
distributing s-bit programs without s-bits and thereby suggesting that
s-bits can be tacked on to binaries very scary.....]

-- 
Ralf Schlatterbeck
email: ralf@zoo.priv.at Fidonet: 2:313/9.81 FAX: +43/1/8034419/23

home help back first fref pref prev next nref lref last post