On Mon, 31 Oct 2005, Shawn Corey wrote: > Yes, you must the the recipient of the change, unless you have > superuser privileges. In other words, you must be $uid. This is > because many UNIX systems have quotas on how much data you can store.
What?? That's hardly why this constraint exists. If anyone can make changes to any other account's files, then there's no point in having ownership constraints at all. This is the broad bedrock of Unix security. Managing user account quotas is only a small facet of that, but there's much more to it. > To "borrow" someone else's capacity, create your file and chown to > someone who doesn't have much data stored. If it has read-access for > everyone, you can get the file back by copying it. Unfortunately the > new version of chown prevent this. The "new" version of chown prevents what? I'm sorry, I'm having trouble following you, but to the extent that I do understand, the description just skims the surface of what's going on. * * * * * This topic is really beyond the scope of this list, but I'll try to do the short, short version of the topic. On Unix systems -- Linux, OSX, Solaris, BSD, Irix, etc -- every file on the system has, among other things, two fundamental properties: ownership, and permissions. Every file belongs to a specific user account, and to a group. Every file has access permissions pertaining to the user/owner, to the group, and to everyone else. The most obvious permissions are read, write, and execute; if you do a `ls -l` command, you'll see these represented as something like rwxrwxrwx -- full permissions for everyone rwxr-xr-x -- read/write/execute for owner, read/execute for others rw-rw-rw- -- read/write for everyone, no execute for anyone r--r--r-- -- read-only access for everyone, no write/execute at all --x--x--x -- execute-only for everyone, no read/write at all Etc. If someone else's file has group-read permission, and I'm in the same group, then I can read -- and so copy -- that file. If I'm not in the same group, but 'other'/'world' has read permission, then again I can read or copy the file. But if both group and world forbids access, or group permits it but I'm not in the right group, then I'm locked out, and cannot read or copy the file. That's it. Nothing about quotas. Only the owner of a file, or an administrative user (root, or someone using sudo to grant themselves root access) can change permissions on a file. Only the admin / root user can reassign ownership from one account to another account. If non-admins could do these things, then you've defeated the whole point of this privilege separation, because anyone can do anything, and you're set back to Windows 95 level security -- i.e. none at all. If this still doesn't make sense to you, then go find a good Unix book and spend half an hour reading the chapter on ownership & permissions. Two excellent ones are _Unix Power Tools_ (has a drill on the cover) and _Unix Administration Handbook_ (red or purple cover with a hand-drawn cartoon illustration; the _Linux Administration Handbok_ is most of the same material but has a green cover). * * * * * But, again, please don't come to the conclusion that this model has anything to do with quota management -- it's really the other way around. Saying that things work this way to support quotas is a bit like, I don't know, perhaps saying that American drivers drive on the right side of the road because that's the side with all the signage. Well, yes, that *is* the side with all the signage, but we don't drive on that side to make reading easier, we put the signs there because that's where all the drivers are. It's a side effect, not the original purpose. Similarly, quota management is a *side effect* of the way permissions are set up -- they're something you get nearly for free once this framework is in place -- but they are not the primary purpose, nor is keeping them correct the primary motivation for why things work, or deliberately don't work in some contexts, the way they do. -- Chris Devers -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
