On Mon, Aug 26, 2024 at 4:52 PM Alejandro Colomar <alx@xxxxxxxxxx> wrote: > > Hi Elliott, > > On Mon, Aug 26, 2024 at 04:15:27PM GMT, enh wrote: > > > Maybe we need to add a "C library/kernel differences" section? > > > > what's your timeline for "currently interesting" vs "just historical"? > > I guess the line is when systems that provide XXX are EOL. > I usually check Debian and RHEL versions for determining that. > > > (though i guess whatever that is, Linux 6.6 is pretty new at less than > > 12 months old!) > > Yup. :) > > > > > > $ grep -rh '^\.SS ' man | sort | uniq -c | sort | tail > > > 5 .SS glibc > > > 7 .SS Authors and copyright conditions > > > 8 .SS Address format > > > 11 .SS Ioctls > > > 11 .SS glibc notes > > > 12 .SS Socket options > > > 13 .SS /proc interfaces > > > 15 .SS ISO/IEC\~8859 alphabets > > > 51 .SS C library/kernel differences > > > 99 .SS Program source > > > > > > Would you mind preparing a patch? > > > > if you just want the trivial removal of the incorrect sentence, sure > > ... if you want a whole new "C library/kernel differences" section > > I prefer the latter: instead of removing and then documenting the > kernel/libc difference, I'd make it in a single commit, so that > git-blame(1) shows the history better. > > > you're probably able to write that ... which is probably a good > > I could... I'd have to research a little bit for it. Do you feel like > writing a draft with what you've found already, and I continue from it? > > If you're busy or lazy, though, just let me know and I'll try to do it > from scratch myself. :) oh, i can definitely make a start... (i was going to at least send you the easiest patch, but then i realized even there there's a bit of a bikeshed opportunity, so i'll just give you all the pieces and let you decide what to do with them!) so i think we have these things to say: 1. AT_SYMLINK_NOFOLLOW _is_ supported for fchmodat(2). 2. but only since Linux 6.6 (except see 4). 3. there's no mention of lchmod(). 4. that function is very old, but it doesn't actually work on glibc until 2.32 (https://sourceware.org/bugzilla/show_bug.cgi?id=14578#c16) where it uses the O_PATH trick that musl and bionic also use (and so doesn't need Linux 6.6). heh, actually trying to write the bits down is probably easiest done as a diff anyway... diff --git a/man/man2/chmod.2 b/man/man2/chmod.2 index ae53fe3c9..c6c54eeca 100644 --- a/man/man2/chmod.2 +++ b/man/man2/chmod.2 @@ -11,7 +11,7 @@ .\" .TH chmod 2 (date) "Linux man-pages (unreleased)" .SH NAME -chmod, fchmod, fchmodat \- change permissions of a file +chmod, fchmod, lchown, fchmodat \- change permissions of a file .SH LIBRARY Standard C library .RI ( libc ,\~ \-lc ) @@ -21,6 +21,7 @@ Standard C library .P .BI "int chmod(const char *" pathname ", mode_t " mode ); .BI "int fchmod(int " fd ", mode_t " mode ); +.BI "int lchmod(const char *" pathname ", mode_t " mode ); .P .BR "#include <fcntl.h>" " /* Definition of AT_* constants */" .B #include <sys/stat.h> @@ -60,9 +61,10 @@ Feature Test Macro Requirements for glibc (see .fi .SH DESCRIPTION The -.BR chmod () -and +.BR chmod (), .BR fchmod () +and +.BR lchmod () system calls change a file's mode bits. (The file mode consists of the file permission bits plus the set-user-ID, set-group-ID, and sticky bits.) @@ -76,6 +78,11 @@ which is dereferenced if it is a symbolic link. .BR fchmod () changes the mode of the file referred to by the open file descriptor .IR fd . +.IP \[bu] +.BR lchmod () +is like +.BR chmod (), +but does not dereference symbolic links. .P The new file mode is specified in .IR mode , @@ -203,8 +210,9 @@ can either be 0, or include the following flag: If .I pathname is a symbolic link, do not dereference it: -instead operate on the link itself. -This flag is not currently implemented. +instead operate on the link itself, +like +.BR lchmod (). .P See .BR openat (2) @@ -285,6 +293,7 @@ is a file descriptor referring to a file other than a directory. specified .BR AT_SYMLINK_NOFOLLOW , which is not supported. +(See C library/kernel differences.) .TP .B EPERM The effective UID does not match the owner of the file, @@ -310,12 +319,22 @@ This interface differs from the underlying Linux system call, which does have a .I flags argument. +.P +Linux 6.6 added the +.BR fchmodat2 () +system call with the POSIX flags argument. .SS glibc notes On older kernels where -.BR fchmodat () +.BR fchmodat2 () is unavailable, the glibc wrapper function falls back to the use of -.BR chmod (). -When +.BR fchmodat () +when no flags are supplied, +or to +.BR chmod () +otherwise. +In the +.BR chmod () +fallback, if .I pathname is a relative pathname, glibc constructs a pathname based on the symbolic link in something along those lines? > > juncture to point out that there's also a whole missing function --- > > there's no mention of lchmod() which seems to have been added in > > GLIBC_2.3.2 (yes, 22 years ago; not to be confused with 2.32 :-) ... > > except i don't think it _worked_ on Linux until glibc sha > > 6b89c385d8bd0700b25bac2c2d0bebe68d5cc05d in 2020? i don't know how you > > want to document that!). > > You probably know that function much better than me. If you want to > have a look at it, it'll be very welcome. (But considering that we've > been waiting for several years, we're not in a hurry.) :) > > Have a lovely day! > Alex > > -- > <https://www.alejandro-colomar.es/>
