[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jordi Sanfeliu
Subject: chown and chgrp won't change on systems without sys_lchown()
Date: Fri, 21 Jul 2023 10:06:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]