atom feed30 messages in org.freebsd.freebsd-securityRe: disk quota overriding
FromSent OnAttachments
Dmitry ValdovMar 17, 1999 3:42 am 
Jay TribickMar 17, 1999 3:49 am 
Fernando SchapachnikMar 17, 1999 3:50 am 
Dmitry ValdovMar 17, 1999 3:52 am 
Dmitry ValdovMar 17, 1999 3:55 am 
Dmitry ValdovMar 17, 1999 4:36 am 
Ladavac MarinoMar 17, 1999 5:37 am 
Mikhail TeterinMar 17, 1999 5:43 am 
Dmitry ValdovMar 17, 1999 5:47 am 
Jon HamiltonMar 17, 1999 6:41 am 
Michael RichardsMar 17, 1999 6:57 am 
Dan TsoMar 17, 1999 7:18 am 
James WyattMar 17, 1999 9:00 am 
James WyattMar 17, 1999 9:08 am 
Daniel C. SobralMar 17, 1999 10:00 am 
Daniel C. SobralMar 17, 1999 10:02 am 
mi...@seidata.comMar 17, 1999 12:14 pm 
David ScheidtMar 17, 1999 3:00 pm 
David H. BrierleyMar 17, 1999 4:59 pm 
Rico PajarolaMar 17, 1999 7:00 pm 
Andrew McNaughtonMar 18, 1999 4:43 am 
Daniel C. SobralMar 18, 1999 5:58 am 
Robert WatsonMar 18, 1999 6:23 am 
Timothy R. PlattMar 18, 1999 6:54 am 
Zahemszky GaborMar 18, 1999 7:55 am 
James WyattMar 18, 1999 8:00 am 
sth...@nethelp.noMar 18, 1999 9:11 am 
James WyattMar 18, 1999 9:53 am 
Jon HamiltonMar 18, 1999 10:13 pm 
Julian AssangeMar 24, 1999 10:34 pm 
Subject:Re: disk quota overriding
From:Robert Watson (rob@cyrus.watson.org)
Date:Mar 18, 1999 6:23:21 am
List:org.freebsd.freebsd-security

On Fri, 19 Mar 1999, Andrew McNaughton wrote:

Dmitry Valdov wrote:

I think that there is only one way to fix it - it's to disable making *hard*links to directory with mode 1777.

I don't use quotas, and don't know a great deal about how they operate, but I think there's another disk filling DOS involving hard links lurking which the above measure would also solve.

If a user starts making hard links to (large and growing) log files, with the new links being placed in /var/mail, then presumably those log files will not be deleted correctly as they are rolled over, and will quickly accumulate.

This could not bring down a system as rapidly as growing the publicly writable directory with lots of links, but it is not desirable system behaviour.

So, yet another risk associated with allowing hard links :-). Again, presumably the answer here is either a) restrict the creation of hard links, and b) make sure that users never have write access to any partition you don't want them to have the ability to preserve files on.

The linking behavior in conjunction with quotas makes a lot of sense: if a user wants to consume someone else's quota, she just hard links to their files so they cannot delete them. And if she are mean, she links to them in private directories so the victim cannot find the links. Even if the user truncates the file, the inode is still consumed in their name.

Robert N Watson

rob@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C

Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message