> -----Ursprüngliche Nachricht----- > Von: Bob Proulx [mailto:[EMAIL PROTECTED] > 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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
