Re: disk quota overriding
Fernando Schapachnik fps...@ns1.sminter.com.ar writes: Are you aware that, due to nature of hardlinks the only extra space is same that for an empty file? Due to this, how many empty files do you No, it's actually 128 bytes less. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
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. Andrew McNaughton -- --- Andrew McNaughton and...@squiz.co.nz http://www.newsroom.co.nz/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Andrew McNaughton wrote: 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. And what the f* is the user doing with read access to the log directory? -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
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 Universityhttp://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 majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Date: Wed, 17 Mar 1999 20:00:17 -0500 (EST) From: David H. Brierley d...@galaxia.com On any machine which allows general users to log in, I strongly recommend making separate file systems for /, /usr, /tmp, and /home, I'll merely point out (since the relevance to -current, per se, is minimal at this point) that there was a recent thread on sage-memb...@usenix.org on how/whether to split up disks into separate filesystems. And mention that folks how are concerned with such issues might find that SAGE and USENIX may well be resources worth checking out. (Domain is usenix.org; I expect y'all can take Web majordomo queries from there.) Cheers, david -- David Wolfskill UNIX System Administrator d...@whistle.comvoice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
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. This is beginning to sound like a broken record: 1) I usually move mail to /var/spool/mail, 2) You can't hard link between /var and /var/spool partitions. On some machines /var/log is a filesys to prevent logfile overflows from filling /var anyway. I usually make a different /var/spool on largish machines to help upgrades go faster. I tend to unmount it, /home, and /usr/local and completely replace the OS. No doubt there are other ways to fix this... - Jy@ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Thu, 18 Mar 1999, Robert Watson wrote: 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. User's manager: Why can't you read your mail or write code? Now, *why* was your unix account blocked? Why did you do *that*? After I make systems fairly secure, I do not hesistate to warn users if they interfere with others. I raraly hesistate in cutting accounts off after warnings. I warn for things like filling /tmp when you vi a 100M application dumo file. I block for things like demonstrably(sp?) injuring others. As I usually log info (ls of dir, clip log msgs, etc...), I usually get cooperation from management. It has also assisted them in gathering enough records to remove such folks from the payroll - they are usually problem folks in other areas as well. Fix social problems with social tools - Jy@ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Hi
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Haven't tested this, but are you sure it fills the filesystem up -
all a hard link is, is a file with the same inode as the
original file (correct me if I'm wrong) - therefore it
doesn't actually use any space other than that required
to store the file entry.
--
Regards,
Jay Tribick netad...@fastnet.co.uk
[| Network Admin | FastNet International | http://fast.net.uk/ |]
[| Finger netad...@fastnet.co.uk for contact info PGP PubKey |]
[| +44 (0)1273 T: 677633 F: 621631 e: netad...@fast.net.uk |]
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Are you aware that, due to nature of hardlinks the only extra space is
same that for an empty file? Due to this, how many empty files do you
think it takes to eat the whole space of / ?
I'm I loosing something?
Regards.
En un mensaje anterior, Dmitry Valdov escribiĆ³:
Hi!
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Fernando P. Schapachnik
Administracion de la red
VIA Net Works Argentina SA
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, Jay Tribick wrote:
Date: Wed, 17 Mar 1999 11:49:32 +
From: Jay Tribick netad...@fastnet.co.uk
To: Dmitry Valdov d...@dv.ru
Cc: freebsd-current@FreeBSD.ORG, freebsd-secur...@freebsd.org
Subject: Re: disk quota overriding
Hi
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Haven't tested this, but are you sure it fills the filesystem up -
all a hard link is, is a file with the same inode as the
original file (correct me if I'm wrong) - therefore it
doesn't actually use any space other than that required
to store the file entry.
^
Yes. But /tmp dir is under root filesystem. So *directory* size of /tmp can be
grown up to free space on /. Which will result 0 bytes free on / :) All
available space will be used to store directory entries.
Dmitry.
PS. Sorry for my english.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, Fernando Schapachnik wrote:
Date: Wed, 17 Mar 1999 08:50:50 -0300 (GMT)
From: Fernando Schapachnik fps...@ns1.sminter.com.ar
To: Dmitry Valdov d...@dv.ru
Cc: freebsd-current@FreeBSD.ORG, freebsd-secur...@freebsd.org
Subject: Re: disk quota overriding
Are you aware that, due to nature of hardlinks the only extra space is
same that for an empty file? Due to this, how many empty files do you
think it takes to eat the whole space of / ?
No. Many empty files can be controlled by INODE QUOTAS.
Hard links can't.
But I can create as many hard links as I need to eat up the whole space of
/...
I'm I loosing something?
Regards.
En un mensaje anterior, Dmitry Valdov escribiŠ”:
Hi!
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Fernando P. Schapachnik
Administracion de la red
VIA Net Works Argentina SA
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Hi!
I think that there is only one way to fix it - it's to disable making
*hard*links to directory with mode 1777.
On Wed, 17 Mar 1999, Dmitry Valdov wrote:
Date: Wed, 17 Mar 1999 14:42:46 +0300 (MSK)
From: Dmitry Valdov d...@dv.ru
To: freebsd-current@freebsd.org, freebsd-secur...@freebsd.org
Subject: disk quota overriding
Hi!
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Dmitry.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
RE: disk quota overriding
-Original Message- From: Dmitry Valdov [SMTP:d...@dv.ru] Sent: Wednesday, March 17, 1999 1:37 PM To: freebsd-current@freebsd.org; freebsd-secur...@freebsd.org Subject: Re: disk quota overriding Hi! I think that there is only one way to fix it - it's to disable making *hard*links to directory with mode 1777. [ML] But only if the quotas have been turned on. BTW, has chown been fixed to the ludicrous SysV semantics that the root and owner can chown a file? If so, the latter has to be disabled in presence of quotas on the volume--otherwise: touch big_file chmod 777 big_file chown root:wheel big_file cat /dev/zero big_file This joke used to work on HPUX 10.something which kept the owner-may-chown semantics even in presence of quotas. It was not funny. (I don't know whether HP has fixed that). /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
=I think that there is only one way to fix it - it's to disable making =*hard*links to directory with mode 1777. Would not it be easier and more practical to make those directories belong to, say, nobody? And make sure nobody's quota is small enough? = Because /tmp directory usually owned by root that why quotas has no effect. = *Directory* size of /tmp can be grown up to available space on / filesystem. -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: disk quota overriding
On Wed, 17 Mar 1999, Ladavac Marino wrote: Date: Wed, 17 Mar 1999 14:37:32 +0100 From: Ladavac Marino mlada...@metropolitan.at To: 'Dmitry Valdov' d...@dv.ru, freebsd-current@freebsd.org, freebsd-secur...@freebsd.org Subject: RE: disk quota overriding -Original Message- From: Dmitry Valdov [SMTP:d...@dv.ru] Sent: Wednesday, March 17, 1999 1:37 PM To: freebsd-current@freebsd.org; freebsd-secur...@freebsd.org Subject:Re: disk quota overriding Hi! I think that there is only one way to fix it - it's to disable making *hard*links to directory with mode 1777. [ML] But only if the quotas have been turned on. Sure. What Core Team thinks about it? Dmitry. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
In message 97a8ca5bf490d211a94ff6c2e55d097...@s-lmh-wi-900.corpnet.at, La davac Marino wrote: } BTW, has chown been fixed to the ludicrous SysV semantics that } the root and owner can chown a file? If so, the latter has to be } disabled in presence of quotas on the volume--otherwise: } } touch big_file } chmod 777 big_file } chown root:wheel big_file } cat /dev/zero big_file } } This joke used to work on HPUX 10.something which kept the } owner-may-chown semantics even in presence of quotas. It was not funny. } (I don't know whether HP has fixed that). Under HP-UX 9.x, the behavior you describe was the default, and it was changable by altering a kernel config parameter and relinking the kernel. The same tunable is available under 10.x, but I'm less certain what the default behavior is there. Whether quotas are enabled or not does not affect the behavior, only the kernel tunable parameter. -- Jon Hamilton hamil...@pobox.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, Jon Hamilton wrote: } touch big_file } chmod 777 big_file } chown root:wheel big_file } cat /dev/zero big_file } This joke used to work on HPUX 10.something which kept the } owner-may-chown semantics even in presence of quotas. It was not funny. } (I don't know whether HP has fixed that). Under HP-UX 9.x, the behavior you describe was the default, and it was changable by altering a kernel config parameter and relinking the kernel. The same tunable is available under 10.x, but I'm less certain what the default behavior is there. Whether quotas are enabled or not does not affect the behavior, only the kernel tunable parameter. We all know that there are oodles of security problems associated with file giveaways. As I recall, all the texts I have ever read on the subject say that unless there is a very good reason to allow giveaways, they should be disabled. -Michael To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Dmitry Valdov wrote:
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
I've always thought that /tmp should be its own filesystem
anyways and I generally make it so. Avoids all sorts of nasties.
It seems silly to mix up the most vital system files on the same
filesystem as the most volitile, damage-prone directory (/tmp). Its
better to newfs /tmp regularly.
As far as the other issue, the ability to fill up any
public 777 directory even with quotas, perhaps the quota system
should look at the 1000 bit and do something special with it.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, Fernando Schapachnik wrote: Are you aware that, due to nature of hardlinks the only extra space is same that for an empty file? Due to this, how many empty files do you think it takes to eat the whole space of / ? They take *less* space than an empty file, just the directory entry. You can see how muchh by looking at the size of the '.' grow when you add one. An empty file still takes an inode, as an 'ls -li [filename]' will show. Now a small amount of anything multiplied by a large number can amount to something. If you have a small root, I can see where you could overwhelm it. It will also take longer and longer to ann the links and lookups in /tmp will take forever. Dmitry Valdov wrote: Because /tmp directory usually owned by root that why quotas has no effect. *Directory* size of /tmp can be grown up to available space on / filesystem. My favorite way is a /tmp filesystem. It solves stability problems unrelated to quotas as well. Same goes for /home if you have real users on your system (not just a server) - Jy@ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, 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'm wondering: are you concerned this is possible, or that you really have a user doing it? I have kicked users off the system for less when they have trounced the machine for others. This is beginning to sound like more of the hard/symlink eruptions last week... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Dmitry Valdov wrote: Hi! I think that there is only one way to fix it - it's to disable making *hard*links to directory with mode 1777. *IF* you are using quotas. Otherwise, it could break things for people. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Jay Tribick wrote:
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Haven't tested this, but are you sure it fills the filesystem up -
all a hard link is, is a file with the same inode as the
original file (correct me if I'm wrong) - therefore it
doesn't actually use any space other than that required
to store the file entry.
You missed the dirty trick... :-) It's the size of +/tmp+ that fills
/. The *directory* size. Because it has to *store* all these
links...
--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org
What happened?
It moved, sir!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
We all know that there are oodles of security problems associated with file giveaways. As I recall, all the texts I have ever read on the subject say that unless there is a very good reason to allow giveaways, they should be disabled. You can play games with quotas anyway, because you are alowd to make hard links to files you don't own. I was considering writing some code to restrict the ability to make hardlinks to files to root and the file's owner. I guess it could either be a global sysctl or a per filesystem mount option. Would there be any interest in this it I put it together? Should it be a mount option or a sysctl? Would anyone consider commiting it if I did write it? David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: disk quota overriding
On Wed, 17 Mar 1999, Ladavac Marino wrote: chown root:wheel big_file AFAIK, only root can 'give ownership away' on most modern Unix'. Later, -Mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, Jon Hamilton wrote: :Under HP-UX 9.x, the behavior you describe was the default, and it :was changable by altering a kernel config parameter and relinking the :kernel. The same tunable is available under 10.x, but I'm less certain :what the default behavior is there. Whether quotas are enabled or not :does not affect the behavior, only the kernel tunable parameter. This is still the default in 10.20. At least, all of the machines around here are that way. It has some uses on test and lab type machines, as it makes some tasks not have to involve root. As default behavior for a production machine, it is damn silly. David Scheidt : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, James Wyatt wrote: Now a small amount of anything multiplied by a large number can amount to something. If you have a small root, I can see where you could overwhelm it. It will also take longer and longer to ann the links and lookups in /tmp will take forever. On any machine which allows general users to log in, I strongly recommend making separate file systems for /, /usr, /tmp, and /home, plus any other areas you expect to grow large. Keeping / and /usr separate prevents people from playing ln tricks to gain root access. Keeping /tmp separate helps prevent /tmp from breaking your system when it fills up (note that I say when and not if). Keeping the users on a separate partition helps keep them under control because you can do things like mount the partition with the nosuid attribute. The only time I ever create a machine with a single large partition is when I am creating a dedicated server machine that will only allow logins from trusted staff members. -- David H. Brierley d...@galaxia.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
