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

[PHILIPP, Axel, Dr.]

> -----Ursprüngliche Nachricht-----
> Von: Bob Proulx [mailto:address@hidden 
> Gesendet: Donnerstag, 14. Februar 2008 00:52
> An: PHILIPP, Axel, Dr.; GNU Coreutils Bug List
> Betreff: Re: AW: cp -p does not work if normal users are 
> allowed to chown files
> 
> 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.

We knew about the problems associated with allowing chown when we did it.
> 
> > 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.

Since the order of preserving special permissions and owner does not make much 
difference for non-root users the reason must lie in the use by root. If root 
(cp -p)s a setuid file owned by user foo and if permissions would be preserved 
before chown then there would be a suid root version of the file for a short 
moment, the classical race condition. So at least the special bits should be 
preserved after changing the owner. I address this with the proposed order of 
operations (see below)
> 
> 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'.

Do you really want that a file owned and made setuid by user 'foo' ends up as a 
file owned (and most likely unintentionally) made setuid to user 'bar'? That's 
the perfect invitation for getting someone else's identity.
My opinion is that a non-root user should preserve set[gu]id bits only if 
copying his or her own files.

> 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

with one more "if" statement you don't have to call chmod twice.

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


Mit freundlichen Gruessen / Best Regards

Axel PHILIPP   Geb. 044/557
Dr. rer. nat., Dipl. Phys.

MTU Aero Engines GmbH
Informationswirtschaft/Entwicklungssysteme (FIE)
Information Management/Engineering Systems (FIE)
Dachauer Str. 665
80995 Muenchen
Germany

Tel  +49 (0)89 1489-4715
Fax +49 (0)89 1489-97533
-- 
MTU Aero Engines GmbH
Geschaeftsfuehrung/Board of Management: Egon W. Behle, Vorsitzender/CEO; Dr. 
Rainer Martens, Dr. Stefan Weingartner, Reiner Winkler
Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Klaus 
Eberhardt
Sitz der Gesellschaft/Registered Office: Muenchen
Handelsregister/Commercial Register: Muenchen HRB 154230