[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 6 Apr 2006 21:33:12 -0600
Eric Blake wrote:
> Michael Konikoff wrote:
> > Why should I not be permitted to change the group permissions on a file
> > owned by another user in the group, ...
Stop at that point in the statement. The only determinant is if you
own the file. If you own it then you can change it. If you don't own
it then you can't change it.
> > when the group ownership of the file
> > and parent directory is set to a group to which we both belong?
The reason this cannot work is because directories have no special
control over files in them. Directories are just files. They are
only special because of a few extra bits set in the inode to say that
they are actually a directory. The ownership of the parent directory
is not involved in whether you can chmod files. Consider this example.
sudo chown -R nobody:nogroup protected
ls -dl protected protected/testfile
ls -dl protected protected/testfile
drwxr-xr-x 2 nobody nogroup 21 2006-04-06 21:04 protected/
-rw-r--r-- 1 nobody nogroup 0 2006-04-06 21:04 protected/testfile
So at this point the file is safe, right? You don't own the
directory, nor the file and are completely locked out. But what if
what you are asking for were allowed? What if you could chmod the
file because you owned the directory and had write permission. What
then? Well in that case I could use that to chmod the file.
ln protected/testfile mydir/
ls -dil * */*
258104450 drwxr-xr-x 2 bob bob 6 2006-04-06 21:06 mydir/
240696922 -rw-r--r-- 2 nobody nogroup 0 2006-04-06 21:04 mydir/testfile
240696921 drwxr-xr-x 2 nobody nogroup 21 2006-04-06 21:04 protected/
240696922 -rw-r--r-- 2 nobody nogroup 0 2006-04-06 21:04 protected/testfile
You can see by the inode numbers that the file in mydir is really the
same file as is also in protected. The same fiel is linked into both
directories. They don't even need to have the same name. That is
So now I own the directory and would be able to chmod the file, if
your capability were allowed. Fortunately it is not allowed.
chmod a+x mydir/testfile
chmod: changing permissions of `mydir/testfile': Operation not permitted
And by this security of the filesystem is maintained. Yeah!
> > Sorry if this is not a bug, it's just incomprehensible to me that
> > using the same user/group/permissions and a different method I can
> > essentially accomplish what chmod says is not permitted.
Hopefully thinking about it with the above example helps to make sense
In the case in which you can overwrite the file the old file would be
removed. It is not the same case. You end up with a file that you
own and with a new set of permissions. Otherwise you could have
another type of privilege escalation which would be a security
> Because POSIX says so.
Agreed. And there is good reason for it. Hopefully this shows one of
> > So it's OK if I overwrite the file with a copy that has the group
> > permissions set the way I want. This doesn't make sense to me.
You are actually not overwriting the file. You are replacing it with
a copy. The new file is a new file. It may be a copy. But it starts
out as a new file with a new set of permissions. The problem to avoid
is not to create privilege escalation. You can only do what the
underlying operating system allows. Then by moving the new file place
the system removes the old file and any permissions associated with
the old file are gone at that time. The file permissions remaining
are those of the new file.
> > The only difference I can see between allowing group permissions
> > to be set directly vs. indirectly is that now the file is owned by
> > mike:www instead of sarah:www. So if this is the reason "Operation
> > not permitted", why not make chmod able to check if current user
> > has write permissions on file and parent directory, and if so,
> > change the group permissions as requested, and change the owner to
> > the current user?
One critical point that I think was missed was that your move did not
overwrite the file.
> address@hidden test]$ mv testFile2 testFile
What actually happened was that the operating system removed the old
file and then renamed your new file into place. It did not chown the
ownership of the file. You can see this by looking at the inode
numbers with 'ls -i' and verify this.
> As odd as your situation is, it can't be changed without breaking lots
> of legacy scripts.
Agreed. Most scripts depend upon classic filesystem behavior. Some
filesystems such as AFS change these rules and it can cause a huge
ripple of changes that are needed.
> It also highlights why sticky directories are generally
> a good idea, so that another user can't overwrite your files.
Actually I think in this case instead of sticky directories what is
needed is sgid directories. Mike and Sara want to be able to
overwrite each others files. The sticky bit would prevent that but
what they want is to have a shared work area where that is allowed.
When the sgid bit is set then the group of the new file created will
be the group of the directory. This behavior was pioneered by BSD and
is the default there. But SysV Unix did not want to change the V7
semantics and required the extra step of setting the sgid bit. (If
all of that is incomprensible gobblygook, don't worry. It is only
history. You can repeat it later.)
chgrp www test
chmod g+s test
ls -dl test/file
-rw-rw-r-- 1 bob www 0 2006-04-06 21:26 test/file
This works quite well. All users that work in the directory need to
be members of the group. The umask needs to allow group access by
default. Usually this would be set up in /etc/profile or some such
when this is desired. Because you are in the group, have group write
access, you can overwrite the files as desired. You still can't chmod
the file if you don't own it. But you can always replace it with a
copy that you do own if needed.
Hope this helps,
- chmod, Michael_Konikoff, 2006/04/06