We're getting a little off topic here, but this is an interesting
discussion, and I think tangentially related: part of good programming
is understanding your security model, so...
On 10/31/05, Chris Devers <[EMAIL PROTECTED]> wrote:
> 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.
>
Well, I don't have a commit bit for any of the kenrels involved, so I
wasn't part of the conversation when chown was changed, but quotas are
the first reason I've always heard given for changing the behavior.
> 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?
>
The "new version" prevents anyone but the superuser from changing a
file's ownership. Actually the change was to the chown and lchown
system calls in various kernels (I think Linux was the first, maybe
Solaris?) not to chown itself.
> 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.
>
But we're talking about ownership, not permissions.
> 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.
>
This would be true if the issue were a user's ability to reassign
other people's files to themselves, which has never been possible. The
issue the OP is (presumably) interested in is reassigning his own
files to another user. If I want to give you a file, there's no more
risk in chowning it to you than in giving your group rwx perms, or
having you cp it, or for that matter emailing it to. These two
workflows accomplish exactly the same thing:
1)
chmod g+r chrissfile;
chgrp chirs chrissfile;
mv chrissfile my_pub_dir;
write chris ttyp3
hey! Your file's ready. Copy if from /home/jay/my_pub_dir ^d
sleep 600; # by which time you hopefully finish copying
rm my_pub_dir/chrissfile # get my space back
2)
chown chris:chris chrissfile;
mv chrissfile /home/chris/dropbox
> 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).
>
> * * * * *
>
I don't think Shawn is confused about how unix permissions work. What
doesn't make sense to him is why at some point in the last six years
or so all *ix vendors changed thier kernels to prevent non-privilaged
users from changnig file ownership flags on their own files since
there doesn't seem to be any real security gain, at least in user
space security. There may be a gain in kernel security, I don't know,
but by far the most visible effect of changing the way ownerships are
handled has been keeping users from stashing chowned files in their
home directories directories under other users names when they start
hitting their quotas. That used to be a big problem. If somebody
downloaded too much pr0n from alt.binaries.pictures.erotica.mature,
they'd do 'ls-l /home', see who had free space, maybe finger them to
see when they logged in last, and then do 'chmod -R g+r News; chown
-RH poor_sap:some_group_im_in News; mv -R News /home/poor_sap/share'.
Nobody was also a popular choice, as well. Needless to say, that
system had problems: people could try to sabotage other people's
quotas, just randomly hide large files to see what they could get away
with, etc.. People would also chown when they meant to chgrp and get
into other kinds of trouble that required admin intervention. It was
an administrative headache. Some admins just took the user executable
flags off chown and stuffed it in /sbin.
Changing the behavior in the kernel isn't a security gain, though, at
least not as far as I can see. It actually leads to some pretty
serious security problems, especially with web programming. It used
to be that users could chown their cgi scripts web directories to
nobody/web. That way all scripts were executed with nobody's
permissions and all reads and writes were excuted with nobody's
permissions. Now, though, server permissions are pretty ugly. You have
a few options. 1) Have an admin chown every file (expensive), 2)
implement a suid solution like suexec (to be avoided) or 3) let
scripts execute with the user's permissions (bad. maybe worse than
suexec); 4) make everything o+rwx (very, very, very bad idea); or 5)
fiddle with groups (ok, but tends to confuse the end user and makes
team projects difficult).
> 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.
>
You've got this a little backwards. Quota management and system
accounting are the raison d'etre of time sharing systems. Those
subsystems were mature (accounting departments made sure of that) when
permissons meant being allowed access to the tty and security meant
having keys to the room. If anything, the traditional three-teired
permission scheme developed out of the system for per user, per
process, and per group accounting.
So what does all this have to do with Perl? Well, admittedly not much.
But hopefully the OP has gotten some idea of why his script was
failing, and why he needs run it as root.
-- jay
--------------------------------------------------
This email and attachment(s): [ ] blogable; [ x ] ask first; [ ]
private and confidential
daggerquill [at] gmail [dot] com
http://www.tuaw.com http://www.dpguru.com http://www.engatiki.org
values of β will give rise to dom!
