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
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
