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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils