chris@mimsy.UUCP (Chris Torek) (07/06/89)
>In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >>... BSD allows only root to change file ownership. In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I certainly hope that V.4 doesn't have this *bogus* restriction. The restriction is not bogus, because the system supports disk quotas. If you could give away your own files, you could: mkdir .hide; chmod 700 .hide chdir .hide create_huge_file >foo chown prof1 foo create_huge_file >bar chown prof2 bar create_huge_file >baz chown prof3 baz All you need do is find someone with a high quota or no quota (such as a professor) who does not often check his own usage (such as a professor) and probably does not care that the disk is 99% full (such as a, er, well, never mind :-) ), and then give away files as necessary to keep under your own quota. You can regain ownership of the file by copying it to another disk partition, removing the original, and copying it back. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
bobmon@iuvax.cs.indiana.edu (RAMontante) (07/06/89)
->>... BSD allows only root to change file ownership. - ->I certainly hope that V.4 doesn't have this *bogus* restriction. - chris@mimsy.UUCP (Chris Torek) <18414@mimsy.UUCP> : -The restriction is not bogus, because the system supports disk quotas. - [ . . . ] -All you need do is find someone with a high quota or no quota (such -as a professor) who does not often check his own usage (such as a -professor) and probably does not care that the disk is 99% full (such There are also many potential problems from hostile users (generally undergraduates) --- consuming someone else's quota can break their running program, make them miss an assignment deadline, etc. Putting obscene or incriminating material in someone else's file system and then "turning them in" can do some real *major* damage. Hope I haven't inspired anyone with this...but hey, I prefer BSD anyway.
peter@ficc.uu.net (Peter da Silva) (07/06/89)
In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >... BSD allows only root to change file ownership. In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I certainly hope that V.4 doesn't have this *bogus* restriction. In article <18414@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > The restriction is not bogus, because the system supports disk quotas. This assume that disk quotas are not bogus in a production environment. That is, outside a university... anyway, I'll rephrase my comment: I certainly hope that V.4 does not impose this bogus restriction if you choose to not make use of disk quotas. I also hope that V.4 doesn't enforce the other bogus restrictions I remember from my years at Berkeley. They didn't call it the "fascist file system" for nothing. [ Pardon my language, but I just saw Bill and Ted's Excellent Adventure ] -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "Bad K&R! Bad!" Personal: peter@sugar.hackercorp.com. `-_-' | -- C. Harald Koch Quote: Have you hugged your wolf today? 'U` | (chk@dciem.dnd.ca)
urban@randvax.UUCP (Mike Urban) (07/06/89)
In article <22969@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >->>... BSD allows only root to change file ownership. (bogus?) >- >There are also many potential problems from hostile users (generally >undergraduates) --- consuming someone else's quota can break their >running program, make them miss an assignment deadline, etc. Putting >obscene or incriminating material in someone else's file system and then >"turning them in" can do some real *major* damage. > There are also many installations that attempt to do cost recovery (or some bureaucratic imitation thereof) by charging users for disk space. Allowing users to give away their large and expensive files to other accounts complicates matters considerably. Not knowing about SysV's ability to give away files can lead to unpleasant surprises on some machines when creating a directory using tar and discovering that the resulting files belong to someone else. -- Mike Urban urban@rand.ORG
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/07/89)
In article <18414@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >>>... BSD allows only root to change file ownership. >In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >>I certainly hope that V.4 doesn't have this *bogus* restriction. >The restriction is not bogus, because the system supports disk quotas. So now the issue becomes: Is the BSD disk quota system bogus? Having had it break things I was doing, I hollered loudly enough that the system administrator who had decided to give me a finite quota changed it back to infinite. Not only does an enforced quota suffer from the same problems as the System V "ulimit", but messages generated by the system to the "appropriate" interactive terminal to warn you that you're approaching your quota can cause all sorts of damage, especially if your "terminal" is a communication channel, not a human-oriented device. (5620 DMD or 630 MTG users should recognize the problem.) There seem to me to be two valid services that can be performed by a disk "quota" system. One of them is to prevent runaway disk consumption such as cat x >> x and the other is to keep users from accumulating junk that fills the available disk. The first problem is dealt with adequately by a resource limit mechanism a la ulimit, or more reliably by a "dynamic" quota monitor attached to the specific session. The second problem can be dealt with administratively, with periodic use of "du|sort -rn" to find where the problems are. Realistic long-term storage quotas really have to be negotiated between the users and the system administrator anyway. These methods of providing disk quota services do not encounter the scenario that you described for the UID-based quota scheme when the file owner is allowed to chown his own file. Most of my use of "su" on our BSD-based systems is simply to chown files. That is indicative of a serious deficiency in normal user services on these systems. I would install a set-UID 0 "chown" (with appropriate checks) except for the hassle I'd get from the system admins around here.
wjc@ho5cad.ATT.COM (Bill Carpenter) (07/09/89)
In article <10501@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > So now the issue becomes: Is the BSD disk quota system bogus? > ... > second problem can be dealt with administratively, with periodic > use of "du|sort -rn" to find where the problems are. Realistic > long-term storage quotas really have to be negotiated between the > users and the system administrator anyway. These methods of > providing disk quota services do not encounter the scenario that > you described for the UID-based quota scheme when the file owner > is allowed to chown his own file. My guess is that the reason that quotas are not handled administratively is because it is too much hassle for some people. Far be it from me to judge whether automating penalites is justified on somebody else's system. However, if I were building a tool to count up how much disk was being used by various parties, I might just make the owner of a directory the responsible person for all the blocks in the normal files immediately under it. Sure, some people leave directories open to being filled up by sneaky people who want to evade disk quotas, but at least my scheme would make the directory owner a co-conspirator. Losing chown to get disk quotas seems about as wise as having an imposed low ulimit. -- Bill Carpenter att!ho5cad!wjc or attmail!bill
bzs@bu-cs.BU.EDU (Barry Shein) (07/09/89)
From: gwyn@smoke.BRL.MIL (Doug Gwyn) >There seem to me to be two valid services that can be performed >by a disk "quota" system. One of them is to prevent runaway disk >consumption such as > cat x >> x >and the other is to keep users from accumulating junk that fills >the available disk. The first problem is dealt with adequately >by a resource limit mechanism a la ulimit, or more reliably by a >"dynamic" quota monitor attached to the specific session. The >second problem can be dealt with administratively, with periodic >use of "du|sort -rn" to find where the problems are. Realistic >long-term storage quotas really have to be negotiated between the >users and the system administrator anyway. These methods of >providing disk quota services do not encounter the scenario that >you described for the UID-based quota scheme when the file owner >is allowed to chown his own file. No, it can't be dealt with with "du|sort -rn" except on very small systems where you can probably just say "someone's hogging the disk" loudly and get the same effect, cause everyone's in the same room anyhow (ok, I exaggerate, but small systems with perhaps a hundred or two entries in the password file.) Or, of course, where you charge hard currency for disk space so the system has built-in feedback which makes such problems relatively rare (on one system like that at Harvard I was the "disk hog", but my funds solved the problem simply enough, they bought me my own washing machine, no tears.) Consider the system Rob Pike was describing in his recent USENIX talk. One major component was a large, organization-wide file server. This is the type of system that easily has tens of thousands of accounts (that's not unusual, I worked with a non-unix system over the last few years that had over 15,000 login accounts in the password file.) You can have dozens if not hundreds of people using more than what was decided was their fair share of disk every day. So you run this script and send them mail. So what? So twenty of them went over their fair share and won't be back for weeks to see your mail (negligently or otherwise, they may have thought they had a good reason to do whatever they did) are way over quota and the disk is busting at the seams on some partitions. Another ten are ignoring you. Don't tell me, you start moving some of their stuff off to tape. Oh what fun, let's have about two dozen people to run this system just to handle sending and answering disk quota mail, putting things to tape, dealing with irate users who find they were put to tape and are quite sure you are mistaken and have inconvenienced them (or believe they can play the political game to make you never do that to them again), get the stuff off tape, deal with people who are quite sure something has gone wrong in this restoral not to mention a phone call or two about how it took so damn long and they now have a dozen people idle which is costing them about a thousand dollars an hour while you deal with the others who are being difficult (ie. human), etc etc etc. Sh*t Doug, I'd own your whole disk farm just by making you do things by written, signed memo. You'd spend your weekends proposing budgets for another dozen secretaries. Obviously little systems don't need quotas very badly (tho, hey, they solve both problems you describe with one model, why introduce two systems where one will do?) The correct answer is that if you personally shouldn't be constrained to quotas either you should have infinite quotas or access to some (set[gu]id) program which lets you set your own quotas (so problem #1, the accidental overrun is still averted, if desirable.) Disk is a finite, valuable resource. Many organizations must manage their disk with many users from diverse administrative domains, and manage it without any realistic chargeback scheme (ie. the disk is essentially or actually free* as far as any individual user is concerned.) The simplest, most obvious way to do this is to assign disk quotas and have the software enforce these quotas automatically instead of turning some poor sap into your local disk slave heavy. My suspicion is you've never managed large systems like this or you wouldn't even dream of suggesting to just send mail to offenders. And they're not rare (hint: just about every university has at least one, if not a few dozen, such systems.) -------------------- * In fact it's often worse than "free" since the disk is being paid for out of overhead by everyone so anything you can grab for yourself is a boon to you, kinda like taxes, you actually can win as long as you're getting more than your fair share and someone else isn't. Sorry, but that's life, you don't fix it by removing quotas. -- -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202 Internet: bzs@skuld.std.com UUCP: encore!xylogics!skuld!bzs or uunet!skuld!bzs
peter@ficc.uu.net (Peter da Silva) (07/10/89)
In article <34422@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: > Don't tell me, you start moving some of their stuff off to tape. Oh > what fun, let's have about two dozen people to run this system just to > handle [ a bunch of stuff that can be handled quite well by 20 lines of shell scripts ] [ comments to the effect that saving hoggy users stuff off to tape isn't workable -- politics, etc... ] Have a look at mainframes, where you generally have lots of disk farms. They have automatic mechanisms to roll stuff off to tape, and bring it back. If it's handled automatically (i.e., they can't dump on a tech aide for following orders), then politics isn't any more a problem than with quotas. This works a *lot* better. > Obviously little systems don't need quotas very badly (tho, hey, they > solve both problems you describe with one model, why introduce two > systems where one will do?) And big systems need better mechanisms than quotas. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "try out a seldom-used feature Personal: peter@sugar.hackercorp.com. `-_-' | of C -- the ``comment''." Quote: Have you hugged your wolf today? 'U` | -- David Gelhar.
uri@arnor.UUCP (Uri Blumenthal) (07/11/89)
From article <WJC.89Jul9124425@ho5cad.ho5cad.ATT.COM>, by wjc@ho5cad.ATT.COM (Bill Carpenter): > Sure, some people leave directories open to > being filled up by sneaky people who want to evade disk quotas, but at > least my scheme would make the directory owner a co-conspirator. > > Losing chown to get disk quotas seems about as wise as having an > imposed low ulimit. Agreed. The same approach I'm using on my systems. So far it works (:-). Uri.
cudcv@warwick.ac.uk (Rob McMahon) (07/11/89)
In article <10501@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >So now the issue becomes: Is the BSD disk quota system bogus? ... an >enforced quota suffer[s] from the same problems as the System V "ulimit" ... Absolutely not. There is no way we could survive without quotas, although I'm sure there are environments that do not need them. We are a University with typically 2,500-3,000 students and staff registered on our Unix machines, and a constant shortage of disk space, cpu power, and terminal access. We have run systems without quotas (4.1bsd and old NFS systems), 1) by politely mailing the big users, 2) by putting a `top 25 bad guys' in message of the day to try to shame people, and 3) by running scripts over night to place people who are over quota in a restricted shell where they couldn't do much more than remove files. 1) is a major load on our time, and doesn't work to any significant extent, or at least not without a lot more work and threats, and generally making ourselves unpopular. 2) has no affect at all to speak of. 3) is extremely unpleasant for the users. Quotas win hands down, particulary the Sun/NFS version where you are given a time limit rather than n logins, both in terms of administration for us, and `niceness' for the users (they get polite warnings as soon as they go over, they're given a week to tidy up, they don't get stuck in some ridiculous environment where they can only `ls', `cat', `mv' ...). The important thing is to allow enough headroom between the hard and soft limits so that people don't suddenly hit the hard limit without warning. Quotas don't suffer from the all the same problems as `ulimit', because they affect only files owned by the user, so incautious setuid programs (not that such exist :-), or programs writing log files don't get caught out by it. (Of course `setrlimit(RLIMIT_FSIZE, ...)' does suffer from this, but that's just a version of ulimit.) >There seem to me to be two valid services that can be performed by a disk >"quota" system. One of them is to prevent runaway disk consumption such as > cat x >> x ... and ... while :; do mkdir gronk cd gronk done ... which every year at least one person does, either by accident, or `to see what would happen'. This is not dealt with by ulimit, and can be much more messy to clean up. Some versions of `rm -r' can't cope with this, and I've even seen fsck fail with `pathname too long' or some such. >and the other is to keep users from accumulating junk that fills the >available disk. Not to say quotas are completely without problems. We get users moving their junk backwards and forwards to /tmp every night, so that they can stay between the hard and soft limits indefinitely. People can't create e.g. lock files in world writable directories under other people's codes on alternative filesystems. >Most of my use of "su" on our BSD-based systems is simply to chown files. >That is indicative of a serious deficiency in normal user services on these >systems. I would install a set-UID 0 "chown" (with appropriate checks) >except for the hassle I'd get from the system admins around here. It's probably just because I've never used a system where joe user can chown a file to someone else, or maybe I'm a bit fik, but can someone explain why people want to do this ? What's wrong with just copying a file if you want a copy owned by someone else ? Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
bzs@bu-cs.BU.EDU (Barry Shein) (07/12/89)
From: peter@ficc.uu.net (Peter da Silva) >Have a look at mainframes, where you generally have lots of disk farms. >They have automatic mechanisms to roll stuff off to tape, and bring it back. >If it's handled automatically (i.e., they can't dump on a tech aide for >following orders), then politics isn't any more a problem than with quotas. > >This works a *lot* better. Agreed (I assume you're referring to systems like IBM's MSS) but so far these systems are not cheap, even for modest systems they can easily cost as much as the rest of the system. Ultimately of course there's some fundamental law at work here where if you don't have controls of any sort the archive system could become the bottleneck (no system I've seen takes less than many seconds to handle an archival restoral request.) The other problem is that you've now overcommitted you disk resources so the possibility exists that some mix of users who want to work today can't because the sum of their archive roll-offs don't fit. Anyhow, just chatting. >And big systems need better mechanisms than quotas. Being as a quota system isn't a whole lot more than managing a few integers I'd be curious to hear what would be needed to improve the current system (sincerely, not a snide remark!) -- -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202 Internet: bzs@skuld.std.com UUCP: encore!xylogics!skuld!bzs or uunet!skuld!bzs
peter@ficc.uu.net (Peter da Silva) (07/12/89)
In article <34515@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: > >And big systems need better mechanisms than quotas. > Being as a quota system isn't a whole lot more than managing a few > integers I'd be curious to hear what would be needed to improve the > current system (sincerely, not a snide remark!) Well, the basic problem with quotas is the same as with such things as hard CPU time limits. The set of problems for which they're an adequate solution is smaller than the set of problems they're used for. How do you allocate quotas? sum(all quotas) == free space on disk? Then you might as well give each user a seperate partition. sum(all quotas) < free space? Then you can still run out of disk space. In either case someone who needs more space temporarily is out of luck... even if there's more space on the disk. How do quotas mesh with multiple partitions? When I was at Berkeley the usual way to get around quotas was to mail files to yourself, or to create subdirectories in /tmp. I would recommend checking quotas on logout only. That can be done in an automatic fashion, without actually putting policy in the kernel. If the user is over quota give them a chance to delete files (or whatever) by starting up a new shell. Don't try to make the quota system unbreakable. If someone wants to be a bad boy, you'll catch them. Don't burn honest users... you're not a cop. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | Th-th-th-that's all folks... Personal: peter@sugar.hackercorp.com. `-_-' | -- Mel Blanc Quote: Have you hugged your wolf today? 'U` | May 30 1908 - Jul 10 1989
jgreely@oz.cis.ohio-state.edu (J Greely) (07/13/89)
In article <4958@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
How do you allocate quotas? sum(all quotas) == free space on disk? Then you
might as well give each user a seperate partition. sum(all quotas) < free
space? Then you can still run out of disk space.
(you do mean sum > space on that last point, don't you?) If we could
use the Berkeley quota system, we would. Unfortunately, it doesn't
work correctly when you mix NFS and multiple vendors. How would we
set it up if we did use it?
Sum(soft quotas) <= free space (about 90% sounds good)
Sum(hard quotas) > free space
Set the soft quotas to a slightly generous estimate for each user
type, and set the hard quotas to a very generous estimate (1.5-2.5
times the soft quota). If soft quotas are properly chosen, most users
will remain below them, leaving free space for the people who need to
go over temporarily. If someone needs a larger quota, and there's not
enough room on the current partition, you juggle people around
partitions until they all fit.
Don't try to make the quota system unbreakable. If someone wants to be a
bad boy, you'll catch them. Don't burn honest users... you're not a cop.
(Does that imply that cops burn honest citizens?)
We can't use real quotas, so we're stuck with a fake quota system (set
quotas for each user on each filesystem, run quot and compare, mail
warnings and summary). When that isn't enough, things get rude. More
than once, I *have* felt like a cop, tracking down an anonymous grad
student who logs in once a week, doesn't read his mail, and has a ten
meg file named thesis-proj.out. Should I delete it? Compress it?
Dump it to tape? Pick on someone else, and find out later it was
garbage? Nuke it, and find out that it was in use by a program vital
to his research?
And of course, not everyone who drastically exceeds their quota is a
"bad boy". Ignorance and laziness are tied as the primary reasons for
unreasonable disk usage around here.
The steady state of disks is full.
-- Ken Thompson
-=-
J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)ellis@godot.psc.edu (James Ellis) (07/14/89)
In article <34422@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >From: gwyn@smoke.BRL.MIL (Doug Gwyn) >>use of "du|sort -rn" to find where the problems are. >... >No, it can't be dealt with with "du|sort -rn" except on very small systems With respect to disk quotas, certainly the du mechanism works well for those environments that can survive with motd or mailed warnings. (Actually, I prefer a du or ls -R that divides by the number of links to the file. But same idea.) If you have users that ignore you then you either need policy sanctions or dynamic quotas built into the kernel. This is all clear enough - I'm sure Doug doesn't need to be lectured about how to run large systems. In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I certainly hope that V.4 doesn't have this *bogus* restriction. >... But what is this fascination System V has with chown? It seems to me to be a security problem begging to be misused. I'll admit that a wide-open chown can make life easier for a few system utilities - I know how hard it is to write a secure setuid program - but do not believe these wins outweigh the problems with users being able to give away files. When I own a file, I have responsibility for it, and I do not like for users to be able to foist that responsibility upon me without my knowledge. If Doug needs to change file ownerships often then he should have his setuid program that checks and logs what he's doing. So. Are there other solutions provided by wide-open chown? (That's your cue, Peter.) I'll summarize replies to me; replies to the net summarize themselves... -- Jim Ellis
peter@ficc.uu.net (Peter da Silva) (07/14/89)
In article <JGREELY.89Jul12135552@oz.cis.ohio-state.edu>, jgreely@oz.cis.ohio-state.edu (J Greely) writes: > (Does that imply that cops burn honest citizens?) Cops have been known to hassle honest citizens. I know a guy who was charged with assaulting a police officer. He was lucky, the judge was smart enough to realise that he wasn't quite stupid enough to throw a punch with five other policemen standing by. > More than once, I *have* felt like a cop, tracking down an anonymous grad > student who logs in once a week, doesn't read his mail, and has a ten > meg file named thesis-proj.out. Should I delete it? Compress it? > Dump it to tape? Under OS-1100 on the Unisys 1100/70 here that file would be automatically checkpointed to tape. And restored when needed. A MUCH better solution. You shouldn't try to apply minicomputer solutions to mainframe problems. > And of course, not everyone who drastically exceeds their quota is a > "bad boy". No, but someone who chowns his files to hide them from the quota system is. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | Th-th-th-that's all folks... Personal: peter@sugar.hackercorp.com. `-_-' | -- Mel Blanc Quote: Have you hugged your wolf today? 'U` | May 30 1908 - Jul 10 1989
peter@ficc.uu.net (Peter da Silva) (07/18/89)
In article <639@godot.psc.edu>, ellis@godot.psc.edu (James Ellis) writes: > So. Are there other solutions provided by wide-open chown? > (That's your cue, Peter.) When I type 'cd //oldsys/path; find . -print | cpio -pvd //newsys/path' I want file ownerships to be maintained. I will leave the possibility of making cpio setuid for those with stronger stomachs. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "A char, a short int, and Personal: peter@sugar.hackercorp.com. `-_-' | an int bit-field were walking Quote: Have you hugged your wolf today? 'U` | through the forest..."