Re: AW: cp -p does not work if normal users are allowed to chown files

[Bob Proulx]

PHILIPP, Axel, Dr. wrote:
> we ran into problems with cp -p on our Linux system when the file system
> is configured to allow chown for normal users (eg
> /proc/sys/fs/xfs/restrict_chown=0). As long as we used the IRIX cp was
> used everything went fine, but with GNU cp we run into errors "cp:
> preserving permissions for `testdir/f1': Operation not permitted"
> because ownership is changed before changing permissions.

There is an FAQ that relates to this topic.

  http://www.gnu.org/software/coreutils/faq/

Search for "Why can only root chown files?".  There it documents some
of the reasons that default policy for most modern operating systems
is to disallow chown.

> I do not understand the argument for this behaviour:
> 
> [cp.c]:  /* Adjust the times (and if possible, ownership) for the copy.
>          chown turns off set[ug]id bits for non-root,
>          so do the chmod last.  */
> 
> because for a non-root user the set[ug]id bits are either cleared by
> chown or may not be set.

Yes.

> To me the reason seems to be that there shouldn't be an intermediate
> suid root binary if root copies a setuid <other user> binary.

Sorry but I don't quite understand your sentence here.  I think you
are saying that this behavior of preserving set[ug]id should be
prevented instead of attempting to be preserved.  If that is not what
you meant then please correct me.

There are several things that go into the rationale of the present
behavior.  Not in any order of important and really just off the top
of my head here are some.

For a non-root user if a binary was set[ug]id and it is copied with -p
then the result should have the same file mode and should still be
set[ug]id.  Otherwise they would need to know that they need to come
by afterward and fix things up.  That would result in the opposite bug
report (and it did) that cp -p was not preserving file modes properly.

The number of operating systems that still allow the old ability to
chown files to other people by non-root is very small.  It was
problematic behavior and modern systems have changed to disallowing it
by default.  GNU cp is of course expected to support the GNU Project
and on such systems the default is not to allow chown for non-root.
The number of users of GNU cp on systems where chown is allowed is
very, very small.  There is no way to justify the return on investment
of trying to support such old-style systems.

It is generally considered a bad idea to allow chown.  Sometimes it is
better not to encourage these things or people will hang on to them
much longer than they should.  It would be a good idea to examine your
reasoning for desiring this behavior.  I believe you would be better
off moving forward and leaving it behind.

> I do not believe that any special permissions should be preserved unless
> the owner (and group) of the destination file is the same as the owner
> of the source file.

It is strongly encouraged that processes and applications that do not
explicitly need root that they run as a non-root user.  This means
that copying and installing and generally working with files is more
often done as a non-root user.  We definitely want that case to work.
A file that was setuid to user 'foo' may be copied by user 'bar'.
This should be preserved.  We definitely want to encourage the ability
of people to work as a non-privileged user and to discourage the
indiscriminate use of root.

> I think the correct order of preserving mode and ownership is
> 
> 1. change the standard permissions
> 2. change owner (if requested)
> 3. if (src_has_special_perms && owner_src == owner_dest && (user == root
> || user == owner_dest)) set special perms on dest file.

As I recall the reason that is not done that way now is that it would
require calling chmod twice instead of once.  Once at the beginning
and once at the end.  Since for the 99.44% case this can be done once
at the end and for the 0.54% case we want to discourage it at all this
shaped the current behavior.

> We first came across the problem with version 5.93 (that's from
> Novell SLED10). Yesterday I downloaded coreutils-6.9, I didn't
> notice that there was e newer version. Since I detected in the
> source code, that the current behaviour is intended, I didn't repeat
> the test with version 6.9.

I believe this has been the behavior for quite a long time.  I am
confident that the newest version will behave the same.  I remember
having issues with it on HP-UX which by default allows chown.  However
HP-UX also allows an administrator to configure chown to be off.  This
is the recommended action.  I strongly recommend configuring
setprivgrp on HP-UX this way.

> This is our testcase:
> use XFS as filesystem (at least 2.5 years ago xfs was the only Linux
> fs which could be configured to allow chown for normal users)

Hmm...  I think it should be a clue that no other system supports the
configuration to allow non-root chown.  If other systems do not allow
this then it adds weight to the position that it is not a good thing
to allow at all.

> do as root
>       echo "0" > /proc/sys/fs/xfs/restrict_chown

I can only believe that the reason you are doing this is that you have
some legacy application that was written on an old SysV Unix system
and was created expecting that behavior.  You have partially ported
this application forward and are now using GNU/Linux systems these
days instead of the older Unix.  Instead of fully porting the
application you modified the new system to be more like the old system
creating a half-way environment that was neither the new way nor the
old way.

I feel your pain.  I have been there myself on HP-UX.  I have had
several applications in that same type of environment which were
developed using chown and then didn't work without it.  But just
because it was once written that way does not mean that it must always
be that way.  In my case I modified my legacy applications such that
they no longer required that feature.  Then they could work on any
POSIX standard system.  I worked that into the schedule as simply one
of the facets of porting applications from the legacy system onto the
modern system.  If this has not been done then the application has not
yet been fully ported.

Additionally another side-benefit was that users didn't get themselves
into problems that only root could fix.  Previously users would untar
files or copy file or whatever and in doing so would create files and
directories that they could not subsequently remove.  They would need
root access to clean up the problem.  Once chown only worked for root
then that whole class of problem disappeared overnight.

I strongly recommend that you determine what needs to be done to
update the application to run without needing chown for non-root.  The
longer that you drag forward the old Unix chown paradigm then the
longer that you will be experiencing this pain and suffering.  It
restricts what platforms you can use to deploy your application.  It
always makes your platform needs "special" as compared to standard
systems today.  It takes some effort to port applications to new
systems but it can be done.

Bob