Re: How to change the Owner of a file
- From: cdevers@xxxxxxxxx (Chris Devers)
- Date: Mon, 31 Oct 2005 09:15:16 -0500 (EST)
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
.
- Follow-Ups:
- Re: How to change the Owner of a file
- From: Shawn Corey
- Re: How to change the Owner of a file
- References:
- How to change the Owner of a file
- From: Rakesh Mishra
- Re: How to change the Owner of a file
- From: Shawn Corey
- How to change the Owner of a file
- Prev by Date: Perl Compile problems..
- Next by Date: Re: How to detect if the other end of the TCP connection has gone offline
- Previous by thread: Re: How to change the Owner of a file
- Next by thread: Re: How to change the Owner of a file
- Index(es):
Relevant Pages
|
|
