Paul Eggert wrote: > Bob Proulx writes: > > Contrary to the statement above my testing shows that FreeBSD chmod > > does not behave this way. > > OK, thanks, clearly NEWS (at least :-) needs to get fixed.
:-) Agreed. Also I applaud your efforts to make working with setgid directories nicer. It is a useful paradigm and GNU should be able to make it a nice way to operate. But I am not sure how far things can go because tar, cpio, etc. all set file permissions too and have their own ideas. But at least the coreutils can be good there. I just worry about drifting too far afield. > The behavior I observe on OpenBSD 3.9 is that sometimes the setgid bit > is preserved, and sometimes not. Hmm... I actually think the mkdir -m case is wrong. But HP-UX works that way too. I imagine it is a SysV'ism. And even though I think it is not behaving literally as I expect it is actually a nicer behavior in many ways. > Clearly there is no consistency here across systems, which gives us a > bit of freedom to decide what is the best thing to do for GNU. Also looking at what the behavior of 'cp -pR' is on systems shows that things are different. On HP-UX 'cp -pR' clears the sgid bit. On HP-UX: mkdir /tmp/t && cd /tmp/t chmod g+s . mkdir foo ls -ld foo drwxrwsr-x 2 rwp esl 96 Jul 25 15:29 foo /bin/cp -pR foo bar ls -ld bar drwxrwxr-x 2 rwp esl 96 Jul 25 15:29 bar That has burned me on occasion. I imagine it is the final chown that is clearing the setgid bit in the kernel but I have not traced through it. Because SysV allows you to give away ownership but only the owner can chmod the file so the chmod must happen first there followed by the chown which clears the setuid bits. But I consider that undesirable behavior. On HP-UX: chmod g+s . /bin/mkdir -m 775 foo ls -ld foo drwxrwsr-x 2 rwp esl 96 Jul 26 22:55 foo /bin/mkdir -m a=r foo ls -ld foo dr--r-Sr-- 2 rwp esl 96 Jul 26 23:11 foo /bin/mkdir -m a+rwx foo ls -ld foo d-----S-w- 2 rwp esl 96 Jul 26 23:37 foo So mkdir seems to work in your desired fashion. The a+rwx case is wacked though. But FreeBSD is exactly the reverse in these two cases. On FreeBSD: chmod g+s . mkdir -m 775 foo ls -ld foo drwxrwxr-x 2 rwp user 4096 Jul 26 22:58 foo /bin/mkdir -m a=r foo ls -ld foo dr--r--r-- 2 rwp user 4096 Jul 26 23:11 foo mkdir foo ls -ld foo drwxr-sr-x 2 rwp user 4096 Jul 26 23:05 foo /bin/cp -pR foo bar ls -ld bar drwxrwsr-x 2 rwp user 4096 Jul 26 23:05 foo In my opinion FreeBSD seems to have two cases right and one case wrong. Of course I am a literal minded person about programs and think they should do exactly what I tell them. Although the HP-UX mkdir -m behavior is probably what you *want* more often. But when heuristics are involved to try to guess what I want instead of what I say it usually works out badly for me in the long run. But FreeBSD gets this case wrong and drops the 's' bit here. /bin/mkdir -m a+rwx foo ls -ld foo drwxrwxrwx 2 rwp user 4096 Jul 26 23:36 foo > However, in normal use it is more convenient if "chmod 755 DIR" > preserves the setgid bit. I don't know. I could be convinced by group concensus otherwise. Using 755 means to me a complete setting which would turn off set-id bits. Using symbolic modes 'chmod a+rwx DIR' I would expect to preserve setgid bits. But 'chmod a=rwx DIR' I would expect to clear set-id. There seems to be a trend to move away from numeric controls. Maybe we preserve legacy behavior for the octal controls but introduce new behavior when using the symbolic controls? But a+rwx already handles the problem. I admit I have not completely thought this problem out. Sorry for rambling here. > Also, it is more consistent with what Solaris does, since Solaris > "chmod 755 DIR" preserves setgid. I am really surprised that Solaris behaves that way. It is opposite of FreeBSD. So the SysV vs BSD differences continue. :-) > If we remove this feature, I'd like to change things to be 100% > consistent with Solaris, and to preserve the setgid bit even if the > user says "chmod 0755 DIR". Personally I prefer the FreeBSD behavior, being the literal minded person that I am. :-) Bob _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
