On Fri, Sep 08, 2000 at 07:00:01PM -0800, Ethan Benson wrote:
> > BTS?
>
> Bug Tracking System
>
> http://www.debian.org/Bugs
>
> i don't remember which tetex package has the long conversion about the
> issue though...
Ahh. Thanks. I looked there initially to see if this was reported for
screen
On Sat, Sep 09, 2000 at 02:56:02AM +, Jim Breton wrote:
> On Sat, Sep 09, 2000 at 01:47:55PM +1100, CaT wrote:
> > > > Still, why does /var/lib/texmf/* need to be publically writeable?
> > >
> > > design flaws in tetex. see the BTS for a long discussion about it.
>
> Which packages adds thes
On Sat, Sep 09, 2000 at 01:47:55PM +1100, CaT wrote:
>
> No. It's just not globally writeable.
ah
> > > Still, why does /var/lib/texmf/* need to be publically writeable?
> >
> > design flaws in tetex. see the BTS for a long discussion about it.
i actually misspoke here, its really /var/spool/
On Fri, Sep 08, 2000 at 06:17:59PM -0800, Ethan Benson wrote:
>
> now what quota (nor moving /var/run/screen) will NOT fix is stuffing
> /var via /usr/bin/logger (that is just a bit more work then the above)
An important difference between those methods of filling the disk is that
the log file m
On Fri, Sep 08, 2000 at 06:33:01PM -0800, Ethan Benson wrote:
> On Sat, Sep 09, 2000 at 01:16:19PM +1100, CaT wrote:
>
> >
> > For my system:
> >
> > [13:09:22] [EMAIL PROTECTED]:/root>> find /var -perm +o+w -mount
> > [13:09:26] [EMAIL PROTECTED]:/root>>
> >
> > I've not had problems. :)
>
>
On Sat, Sep 09, 2000 at 01:16:19PM +1100, CaT wrote:
>
> For my system:
>
> [13:09:22] [EMAIL PROTECTED]:/root>> find /var -perm +o+w -mount
> [13:09:26] [EMAIL PROTECTED]:/root>>
>
> I've not had problems. :)
you have removed /var/lock? and i presume made /var/tmp its own
partition.
> Stil
On Sat, Sep 09, 2000 at 01:10:23PM +1100, Herbert Xu wrote:
>
> How will they do that if the only thing owned by screen are the directories?
> You can always do fstat after an open.
oh i misunderstood you, what would happen if they removed the socket?
i would guess nothing if sockets work like an
On Fri, Sep 08, 2000 at 10:07:37PM -0400, Matthew W Miller wrote:
> {Big Snip}
> How would a quota stop the user from stuffing /var to its limit? Isn't
> that part of the problem where the user could stuff /var and hemorrage the
> logs?
Through not allowing the user full access to the free space.
On Fri, Sep 08, 2000 at 10:07:37PM -0400, Matthew W Miller wrote:
> {Big Snip}
> How would a quota stop the user from stuffing /var to its limit? Isn't
> that part of the problem where the user could stuff /var and hemorrage the
> logs?
hmm quota seems to stop that just fine here:
[EMAIL PROTECTE
On Fri, Sep 08, 2000 at 05:52:42PM -0800, Ethan Benson wrote:
> On Sat, Sep 09, 2000 at 12:00:19AM +1100, CaT wrote:
> > What screen does there is to create subdirs which are then used
> > to hold a users pipes. Now these subdirs are owned by the user
> > that runs screen. The hassle with this is t
On Fri, Sep 08, 2000 at 05:54:32PM -0800, Ethan Benson wrote:
>
> i think this is a bad idea, if another hole is found in screen then
> users can spy on other users sessions. as it is now if a hole is in
> screen users can mess with the utmp file, thats it. which is not that big a
> deal. (i have
{Big Snip}
How would a quota stop the user from stuffing /var to its limit? Isn't
that part of the problem where the user could stuff /var and hemorrage the
logs?
~mmiller
::>
::>more headaches for /tmp cleaners and it does not solve any of the
::>above problems. to solve the above problems enfo
On Sat, Sep 09, 2000 at 10:30:26AM +1100, Herbert Xu wrote:
> CaT <[EMAIL PROTECTED]> wrote:
> >
> > What screen does there is to create subdirs which are then used
> > to hold a users pipes. Now these subdirs are owned by the user
> > that runs screen. The hassle with this is that it gives the use
On Sat, Sep 09, 2000 at 12:00:19AM +1100, CaT wrote:
> After installing this utility (which has to be amongst my very
> favourite) I noticed something interesting int he way it behaves.
> Basically, screen does what I first thought of when compiling it
> for myself, which is to put its pipes in /va
On Fri, Sep 08, 2000 at 07:00:01PM -0800, Ethan Benson wrote:
> > BTS?
>
> Bug Tracking System
>
> http://www.debian.org/Bugs
>
> i don't remember which tetex package has the long conversion about the
> issue though...
Ahh. Thanks. I looked there initially to see if this was reported for
scree
On Sat, Sep 09, 2000 at 02:56:02AM +, Jim Breton wrote:
> On Sat, Sep 09, 2000 at 01:47:55PM +1100, CaT wrote:
> > > > Still, why does /var/lib/texmf/* need to be publically writeable?
> > >
> > > design flaws in tetex. see the BTS for a long discussion about it.
>
> Which packages adds the
On Sat, Sep 09, 2000 at 01:47:55PM +1100, CaT wrote:
>
> No. It's just not globally writeable.
ah
> > > Still, why does /var/lib/texmf/* need to be publically writeable?
> >
> > design flaws in tetex. see the BTS for a long discussion about it.
i actually misspoke here, its really /var/spool
On Fri, Sep 08, 2000 at 06:17:59PM -0800, Ethan Benson wrote:
>
> now what quota (nor moving /var/run/screen) will NOT fix is stuffing
> /var via /usr/bin/logger (that is just a bit more work then the above)
An important difference between those methods of filling the disk is that
the log file
On Fri, Sep 08, 2000 at 06:33:01PM -0800, Ethan Benson wrote:
> On Sat, Sep 09, 2000 at 01:16:19PM +1100, CaT wrote:
>
> >
> > For my system:
> >
> > [13:09:22] root@nessie:/root>> find /var -perm +o+w -mount
> > [13:09:26] root@nessie:/root>>
> >
> > I've not had problems. :)
>
> you have re
On Sat, Sep 09, 2000 at 01:16:19PM +1100, CaT wrote:
>
> For my system:
>
> [13:09:22] root@nessie:/root>> find /var -perm +o+w -mount
> [13:09:26] root@nessie:/root>>
>
> I've not had problems. :)
you have removed /var/lock? and i presume made /var/tmp its own
partition.
> Still, why does
On Sat, Sep 09, 2000 at 01:10:23PM +1100, Herbert Xu wrote:
>
> How will they do that if the only thing owned by screen are the directories?
> You can always do fstat after an open.
oh i misunderstood you, what would happen if they removed the socket?
i would guess nothing if sockets work like a
On Fri, Sep 08, 2000 at 10:07:37PM -0400, Matthew W Miller wrote:
> {Big Snip}
> How would a quota stop the user from stuffing /var to its limit? Isn't
> that part of the problem where the user could stuff /var and hemorrage the
> logs?
Through not allowing the user full access to the free space.
On Fri, Sep 08, 2000 at 10:07:37PM -0400, Matthew W Miller wrote:
> {Big Snip}
> How would a quota stop the user from stuffing /var to its limit? Isn't
> that part of the problem where the user could stuff /var and hemorrage the
> logs?
hmm quota seems to stop that just fine here:
[eb@socrates e
On Fri, Sep 08, 2000 at 05:52:42PM -0800, Ethan Benson wrote:
> On Sat, Sep 09, 2000 at 12:00:19AM +1100, CaT wrote:
> > What screen does there is to create subdirs which are then used
> > to hold a users pipes. Now these subdirs are owned by the user
> > that runs screen. The hassle with this is
On Fri, Sep 08, 2000 at 05:54:32PM -0800, Ethan Benson wrote:
>
> i think this is a bad idea, if another hole is found in screen then
> users can spy on other users sessions. as it is now if a hole is in
> screen users can mess with the utmp file, thats it. which is not that big a
> deal. (i hav
{Big Snip}
How would a quota stop the user from stuffing /var to its limit? Isn't
that part of the problem where the user could stuff /var and hemorrage the
logs?
~mmiller
::>
::>more headaches for /tmp cleaners and it does not solve any of the
::>above problems. to solve the above problems enf
On Sat, Sep 09, 2000 at 10:30:26AM +1100, Herbert Xu wrote:
> CaT <[EMAIL PROTECTED]> wrote:
> >
> > What screen does there is to create subdirs which are then used
> > to hold a users pipes. Now these subdirs are owned by the user
> > that runs screen. The hassle with this is that it gives the us
On Sat, Sep 09, 2000 at 12:00:19AM +1100, CaT wrote:
> After installing this utility (which has to be amongst my very
> favourite) I noticed something interesting int he way it behaves.
> Basically, screen does what I first thought of when compiling it
> for myself, which is to put its pipes in /v
CaT <[EMAIL PROTECTED]> wrote:
>
> What screen does there is to create subdirs which are then used
> to hold a users pipes. Now these subdirs are owned by the user
> that runs screen. The hassle with this is that it gives the user
What about making screen setuid screen and make screen the owner of
CaT <[EMAIL PROTECTED]> wrote:
>
> What screen does there is to create subdirs which are then used
> to hold a users pipes. Now these subdirs are owned by the user
> that runs screen. The hassle with this is that it gives the user
What about making screen setuid screen and make screen the owner o
FYI - Debian potato and woody versions fall into this...I will have
fixed .deb's done this evening and uploaded to the appropriate locations.
Ivan
--
Ivan E. Moore II
[EMAIL PROTECTED]
http://snowcrash.tdyc.com
GPG KeyID=90BCE0DD
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645
On Wed, Sep 06, 2000 at 17:50:05 -0500, Herbert Ho wrote:
> how about encrypted loopback? just need the crypto/int'l patch for the
> kernel. no other software. but then again it doesn't use gpg
That's not a disadvantage, as encrypted filesystems are a different area
(protect against differen
FYI - Debian potato and woody versions fall into this...I will have
fixed .deb's done this evening and uploaded to the appropriate locations.
Ivan
--
Ivan E. Moore II
[EMAIL PROTECTED]
http://snowcrash.tdyc.com
GPG KeyID=90BCE0DD
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 764
On Wed, Sep 06, 2000 at 17:50:05 -0500, Herbert Ho wrote:
> how about encrypted loopback? just need the crypto/int'l patch for the
> kernel. no other software. but then again it doesn't use gpg
That's not a disadvantage, as encrypted filesystems are a different area
(protect against differe
On Fri, 8 Sep 2000, Michael Meskes wrote:
> On Fri, Sep 08, 2000 at 09:13:50AM -0400, Michael Stone wrote:
> > > deb http://security.debian.org potato/updates main contrib non-free
> > > tree in the sources.list file of my system running woody?
> >
> > Yes. Put it at the bottom of the list.
>
>
On Fri, Sep 08, 2000 at 09:13:50AM -0400, Michael Stone wrote:
> > deb http://security.debian.org potato/updates main contrib non-free
> > tree in the sources.list file of my system running woody?
>
> Yes. Put it at the bottom of the list.
Sorry, but that does really make sense to me. The upload
On Fri, Sep 08, 2000 at 02:06:15PM +0100, Tim Haynes wrote:
> CaT <[EMAIL PROTECTED]> writes:
>
> [snip sensible stuff]
> > As such I reckon it's best if the screen directory is left in /tmp where
> > the authors initially put it. It's inconvenient but doesn't cause the
> > problems above.
>
> No
On Fri, Sep 08, 2000 at 09:12:38AM -0400, Michael Stone wrote:
> On Sat, Sep 09, 2000 at 12:00:19AM +1100, CaT wrote:
> > a. a possible way around quotas set on /home b. a method of fully
> > filling up /var, thereby potentially causing log entries to be
> > lost which, in turn, gives the user anic
On Fri, Sep 08, 2000 at 01:08:18PM +0200, Giacomo Mulas wrote:
> Am I getting anything wrong here? Should I include the
> deb http://security.debian.org potato/updates main contrib non-free
> tree in the sources.list file of my system running woody?
Yes. Put it at the bottom of the list.
--
Mik
On Sat, Sep 09, 2000 at 12:00:19AM +1100, CaT wrote:
> a. a possible way around quotas set on /home b. a method of fully
> filling up /var, thereby potentially causing log entries to be
> lost which, in turn, gives the user anice, untracable way of then
How would this be different from putting thi
On Fri, 8 Sep 2000, Pollywog wrote:
> I think you need to run 'apt-get update' or update from 'dselect' if that is
> what you are using. There is a newer version of libc for woody.
Where is that? I frequently run apt-get update etc. on my system, and
moreover I just checked ftp.debian.org (216.6
CaT <[EMAIL PROTECTED]> writes:
[snip sensible stuff]
> As such I reckon it's best if the screen directory is left in /tmp where
> the authors initially put it. It's inconvenient but doesn't cause the
> problems above.
No indeed, but you have problems with folks who periodically clean out
their /
After installing this utility (which has to be amongst my very
favourite) I noticed something interesting int he way it behaves.
Basically, screen does what I first thought of when compiling it
for myself, which is to put its pipes in /var/run/screen.
What screen does there is to create subdirs wh
I think you need to run 'apt-get update' or update from 'dselect' if that is
what you are using. There is a newer version of libc for woody.
--
Andrew
On 08-Sep-2000 Giacomo Mulas wrote:
> About the recent security advisory on the glibc vulnerabilities:
> fixed versions have been released
About the recent security advisory on the glibc vulnerabilities:
fixed versions have been released for slink and potato, but (as far as I
know) none for woody. I am currently using the potato version, recompiled
from sources, on my woody box, apparently with no problems, but should not
the
On Fri, 8 Sep 2000, Michael Meskes wrote:
> On Fri, Sep 08, 2000 at 09:13:50AM -0400, Michael Stone wrote:
> > > deb http://security.debian.org potato/updates main contrib non-free
> > > tree in the sources.list file of my system running woody?
> >
> > Yes. Put it at the bottom of the list.
>
>
On Fri, Sep 08, 2000 at 09:13:50AM -0400, Michael Stone wrote:
> > deb http://security.debian.org potato/updates main contrib non-free
> > tree in the sources.list file of my system running woody?
>
> Yes. Put it at the bottom of the list.
Sorry, but that does really make sense to me. The upload
On Fri, Sep 08, 2000 at 02:06:15PM +0100, Tim Haynes wrote:
> CaT <[EMAIL PROTECTED]> writes:
>
> [snip sensible stuff]
> > As such I reckon it's best if the screen directory is left in /tmp where
> > the authors initially put it. It's inconvenient but doesn't cause the
> > problems above.
>
> N
On Fri, Sep 08, 2000 at 09:12:38AM -0400, Michael Stone wrote:
> On Sat, Sep 09, 2000 at 12:00:19AM +1100, CaT wrote:
> > a. a possible way around quotas set on /home b. a method of fully
> > filling up /var, thereby potentially causing log entries to be
> > lost which, in turn, gives the user ani
On Fri, Sep 08, 2000 at 01:08:18PM +0200, Giacomo Mulas wrote:
> Am I getting anything wrong here? Should I include the
> deb http://security.debian.org potato/updates main contrib non-free
> tree in the sources.list file of my system running woody?
Yes. Put it at the bottom of the list.
--
Mi
On Sat, Sep 09, 2000 at 12:00:19AM +1100, CaT wrote:
> a. a possible way around quotas set on /home b. a method of fully
> filling up /var, thereby potentially causing log entries to be
> lost which, in turn, gives the user anice, untracable way of then
How would this be different from putting th
On Fri, 8 Sep 2000, Pollywog wrote:
> I think you need to run 'apt-get update' or update from 'dselect' if that is
> what you are using. There is a newer version of libc for woody.
Where is that? I frequently run apt-get update etc. on my system, and
moreover I just checked ftp.debian.org (216.
CaT <[EMAIL PROTECTED]> writes:
[snip sensible stuff]
> As such I reckon it's best if the screen directory is left in /tmp where
> the authors initially put it. It's inconvenient but doesn't cause the
> problems above.
No indeed, but you have problems with folks who periodically clean out
their
After installing this utility (which has to be amongst my very
favourite) I noticed something interesting int he way it behaves.
Basically, screen does what I first thought of when compiling it
for myself, which is to put its pipes in /var/run/screen.
What screen does there is to create subdirs w
I think you need to run 'apt-get update' or update from 'dselect' if that is
what you are using. There is a newer version of libc for woody.
--
Andrew
On 08-Sep-2000 Giacomo Mulas wrote:
> About the recent security advisory on the glibc vulnerabilities:
> fixed versions have been released
About the recent security advisory on the glibc vulnerabilities:
fixed versions have been released for slink and potato, but (as far as I
know) none for woody. I am currently using the potato version, recompiled
from sources, on my woody box, apparently with no problems, but should not
the
56 matches
Mail list logo
