chown and chgrp won't change on systems without sys_lchown()

[Jordi Sanfeliu]

Hello,

I've detected that chown and chgrp commands will not change the 
owner/group of a device file (char or block) that doesn't exist on a 
system that don't has the system call sys_lchown.

The example below creates a new ramdisk block device file called 'ram5', 
and after this it fails to set the owner and group:

# mknod ram5 b 1 5
# ls -l ram5
brw-r--r-- 1 root root 1, 5 Jul 21 07:10 ram5
# chown root:disk ram5
chown: changing ownership of 'ram5': No such device or address
# chgrp disk ram5
chgrp: changing group of 'ram5': No such device or address


Since this sixth ramdisk drive does not exist, chown and chgrp will fail.

If I understand correctly the trace is as follows:

The message 'changing ownership of 'ram5': No such device or address' is 
output in lines 481-485 of coreutils/src/chown-core.c because the 
variable 'ok' was set to zero (not ok) after calling chownat() in line 455.

chownat() actually calls to fchownat() in line 66 of 
gnulib/lib/openat.h, which in turn calls to chown() on systems that 
!HAVE_FCHOWNAT in line 75 of gnulib/lib/at-func.c (which was included in 
line 51 of gnulib/lib/fchownat.c).

Finally chown() (actually rpl_chown() in gnulib/lib/chown.c), in the 
section '# if CHOWN_MODIFIES_SYMLINK' (lines 82-119), opens our file 
'ram5' without taking into consideration that it is a device file. This 
fails irremediably and finally returns an error to the original caller 
chownat() in chown-core.c.

I've not made the same tracing for the chgrp command, but I assume it 
will be similar to explained above.

I think that it would be solved by just adding the following condition 
right before the line 106 in gnulib/lib/chown.c:

&& (S_ISCHR (st.st_mode) || S_ISBLK (st.st_mode))


Does this sound reasonable to you?
Best regards.

--
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat