Re: chown(2) vs lchown(2) and application breakage

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Tue, 26 May 1998 10:26:29 +1000

Anders Hammarquist writes:
> A few patch levels ago we were blessed with a lchown() syscall and chown()
> started following symlinks (until that time chown() had really been an
> lchown()). On the x86 and m68k (at least) lchown() eventually received the
> same syscall number (16) as the old chown() and the new chown() got a new
> syscall number. On the alpha, chown() is still 16 and lchown() is "new" (I
> suspect this has to do with wanting to remain compatible with Digital
> Unix).
>
> For the past few days we've been having a discussion of what's right and
> how to fix it on Debian's alpha port list (start reading at
> http://www.debian.org/Lists-Archives/debian-alpha-9805/msg00060.html if
> you are interested).
>
> >From what I can see, the semantics change only affects programs that
> expect chown() to act as lchown() (very few, but unfortunately the Debian
> package tool dpkg is one of them). The syscall number change that has been
> used on i386 and m68k only fix it for a libc that does not know about the
> new lchown(), binaries that break with unchanged syscall numbers as on the
> alpha will break on i386 and m68k when libc is recompiled with the new
> syscall numbers.
>
> This needs fixing (though exactly how may not be immediately obvious). To
> me, any application that expects lchown() behaviour should call lchown().
> Unfortunately this alone is not enough, since lchown() will fail with
> ENOSYS on some architectures for kernels < 2.1.8x, so libc (or the
> applications) need to call chown() iff lchown() fail with ENOSYS (I not
> sure where would be cleanest, but I leaning towards libc).
>
> On a related note, chown() will fail with ENOSYS with a libc compiled for >
> 2.1.8x on a kernel < 2.1.8x for those architectures that changed syscall
> numbers unless it is handled in libc. Perhaps I should advocate that the
> numbers be changed back? :-)

I agree with you: syscall #16 should be chown(). However, my complaint
about this was ignored in the name of "compatibility". In this
context, "compatibility" meant "compatibility with old versions of
Linux", not "compatibility with POSIX". I encourage you to push for
this to be fixed: syscall #16 should follow symlinks. Binaries that
break were relying on Linux's non-POSIX behaviour, so I don't have
much sympathy.

Anyway, for i386 I've written a patch for libc 5.4.44 which I sent to
H.J. last night. This patch creates the lchown() syscall interface and
implements a chown() function which uses syscall #182 if available,
otherwise falls back to syscall #16. So if we can't get the kernel
fixed, this patch is the next best thing.

Regards,

Richard....

begin 644 chown-patch.gz
M'XL("/4M:34"`V-H;W=N+7!A=&-H`.U96W/BN!)^QK^BM\X^P!@G&$,@9+,U
M3#:9Y51N%2<UE:JI<@E;!E6,S4HR&>KL_O?3DLW%!`@D>=B'28(M]TW=K=;7
MB@E8&(*5\FN(6-^WF@>-@T;CD,5^E`;T4$R%^O@DB@Z&6F(]R[`LZW4#)3>-
MX3J9`-3!=CJ-=J?1`/OXN&68IKG%>NDJB>&*3*'>!+O=L6N=YK'2:QN?/X-E
MMZHM,/7U\V<#_A/0D,44W$?7DVQ$2R7;*5+'G$Z\T5.<!,AK%'G^<*3)3<,J
MDI/G&,E'AKE,CA;T@I4^I^0)R:TB.8D"(8E$1KO(B`2E2OXX#ZA=;:J(VE7[
MZ$5,@DI.Q8`I+UNU(F^PS+-7H_9EI.CU8@Q<>H(-.)4ICY'KK.,27[)$<1OK
MN&.>^",BGI#?7,NG<<#B`;*/UK'5(@7/A$D4:*T3^"NE*65QF*!`>YV`2(6:
M`]G'13:N-%&Y:-=6Z,^<2549;;O(T.L)Q1^[O9*QO"X+PG-E`S#M*N"P=/@)
M?BO4\>_PZ=`(MFZX-&9"!JM[;4;=N,UF`J5O-,AVRK':*<YQIVFKG7+T<H?-
M58J;RVGAW]+F:CM5NX;%J.YU78SJ%T,[&Y)X0$$.*6#8E`.)`QCP)!U#$L)%
M[_+\`%2\%OTA*8^!Q1*\/&>>=POE,CXEL9#@#PF'3YX7LHA6#:M4*J%`R@)/
M*6C;51P,<H*>HE(Y,6#)\.MF`:UF/[O8-@M.1Z^;-Y77>YO>T?!.V<"R8R%6
M*4H_N.?>%_>/'99)D=4\."`2+OX`)B#!O01)G*W>^FK5A81E'="QP(<X_7%X
M19ZHMJ1Y6P1>U/`6V1T:QC;MY<IN=6R[TZ@M*KOA5-M@ZJNJZE*B88H?^,#I
M,XN#;*R`.1M)&D79:)1PZN,'A]]1T5.PBQP:2\ZH4*)R&I,178P\I892_G.0
M*X7R69&BI*\GB8.1&.BI_<EL1(()WC52J0%B2.[?=]PC"E-DA`]/6$LT\B:4
M"X1H)(P3A!K?L-R[L[I[BMX1WZ="'+AZ]RD+V0C[7#["NLA&42*H'@7I&._?
ML?A>FR?;>3B?N>M\!?3<,*]**H[KFDA_8%(R?K@P$RYLAPM3H1^CMS,38<*?
M,K)JNV'F$RX#Q=TS'Z=Z/%_()=:`C^<J3([X;#Q>B(S'N;:JJ):M#B+ZJBM*
M^$,:*"D]2".J+&3$*:-1,']"$6Q5+,&EGGHC\B/W9QV3Q7,MSC4/<83R"5%1
MAP&11$QC/S<0DS@1$:7C0N+UPKGP5YI(XNML>5X<"H%6_#QY%N9B?LZ8Q;KT
MI,\2!R[6QTYR<PA%%<`Z<=Q3F"T)%O9LD.:;QO,F>N5\R.\*W%#-/?VUC#?;
MK8`>U&<#QZWL#E2+BM^$'W.)7:!J+EQR%8+2/C91L(\ZCM-QZ@IMFENQ:J%^
M/TSAOP3/$]BP:YV:^D-U/.'I-ERMU\&L56NJLBP%Z\EXRME@**%\5E'3V%5U
MK<,%IWA*21!?"*=PD:0Q%@7NV"KTL"X,ZWZ($*^!&N]CPN6L#7R]?H`SN&1]
M3O@4!97H"E6IA,J^R.V?P#1)`8$)X2K`XP1G_52B9:FZS&'"#0NW*PNGBH*.
M8/=1,V&]CL3RM#/S7RDV*!+!;=J/F(]DG\:"`A&&-58D@64/_:G6VQ3G"5"&
M?`XY4F'GR&8RK-Q>%1(.95PL])UCMU-:%71X"A&1"\7-*5A$&F`7U]X,L7MD
M/10C?691!'T*J:!A&N&)!D7A6^_^SYN'>^A>/\*W[MU=]_K^\01%Y3!!+IW0
MS!`;C2.&=C$J3F(Y1><-Z^K\[NQ/5.A^Z5WV[A^5_Q>]^^MSUX6+FSOHPFWW
M[KYW]G#9O8/;A[O;&U>=O5Q*9QE6L6]-,>XSW=8@H)*P2.C@'W%M!;H7!3`D
M$ZJ:$V43=(Z`C^7W^@K.4PXD2N*!CO9EK9VH)KLXB9S=W#[VKK\>7/:^8!`]
M##].9#7K@R"3K8N?%7D5CEI-;/Q"0'>B3I1G9-3G+!C@TE]UH5:WG>,J/+C=
M_("*_^KEAV)]7L?=B4=U1<9#_5GW\M+SH*QW:16<"F(C_J^T#]Q$K^--M!?@
M1*]"QG;$F>NOG(_JG?K2R5^!C:EQ!R''?`?DF+M"CJE$WPTYY@=!COD!D&/N
M"SF;4K`OY)COA!SS_9!C[@TY&/S[(<?\",@QWPLYYG;(P4C700Z2ER`G6F".
MN2_FK!ZR-X/!BN1N"+2B]%8@6C53Q*-FJU-K_\2CGWCT$X_^%7A4V*UO@:7\
M5<%&0)B]2M@!@G+1MP'/3'D%;AH=Y^@%W#2<C7#3T'!SI*^M5T$'`/;`'2W]
M?NA!,Q^%/FCJ(P`(S;P!@S:E8V\80D/O12(T\0%@I/.P/QZAV@=`TF(1WH-*
MH$!)&]L+F)K'<$\QL11N(^)3L,!-E;KCU#)K7Q(AE7B&4[9MV4ZMM06L#N5T
M3(7&JP5]]NU&@4@YCY,5FBJ@>+!*5%;9B.8@N.F-_?+[^C&1PRID[^GSM_39
M._H-WRD4OT1ZDSW#7'SUL8^N8?Y/)UI[@@@^(=%)1E"OXK`$%3V)`B][YPNG
M4#O)BP]8".5?%KQ*1D5[):6D$^P)HLKQ-'O2FJ5L%J2M!E[.?)UYJ?T[4=9P
M'BC/U-"#"OS]-Y2U2?CE%,ZO;[`U5:`"V3>7BSA*!<]M1<FT3I?=RP/^)[OE
0-J*M/OUC_!]_^E5^+!\`````
`
end

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu