[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: AW: cp -p does not work if normal users are allowed to chown files
PHILIPP, Axel, Dr.
AW: AW: cp -p does not work if normal users are allowed to chown files
Thu, 14 Feb 2008 09:23:26 +0100
> -----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.
> 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.
> > 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.
Mit freundlichen Gruessen / Best Regards
Axel PHILIPP Geb. 044/557
Dr. rer. nat., Dipl. Phys.
MTU Aero Engines GmbH
Information Management/Engineering Systems (FIE)
Dachauer Str. 665
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
Sitz der Gesellschaft/Registered Office: Muenchen
Handelsregister/Commercial Register: Muenchen HRB 154230