Re: chmod

[Michael_Konikoff]

Thank you for your detailed response. I am learning a lot here. I'll try
the sgid/umask approach.

Mike K.


address@hidden (Bob Proulx) wrote: -----


To: address@hidden
From: address@hidden (Bob Proulx)
Date: 04/06/2006 11:33PM
cc: address@hidden
Subject: Re: chmod

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.

 mkdir protected
 touch protected/testfile
 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.

 mkdir mydir
 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
just incidental.

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
of this.

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
vulnerability.

> Because POSIX says so.

Agreed.  And there is good reason for it.  Hopefully this shows one of
the reasons.

> > 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.)

 mkdir test
 chgrp www test
 chmod g+s test
 umask 02
 touch test/file
 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,
Bob

This e-mail and any attachments are confidential. If you receive this
message in error or are not the intended recipient, you should not retain,
distribute, disclose or use any of this information and you should destroy
the e-mail and any attachments or copies.