coreutils
[Top][All Lists]
Advanced

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

Re: chmod don't affect referenced file of symbolic links


From: Pádraig Brady
Subject: Re: chmod don't affect referenced file of symbolic links
Date: Sat, 16 Sep 2023 14:59:48 +0100
User-agent: Mozilla Thunderbird

On 16/09/2023 07:26, mn wrote:
Hello,

I would like to suggest and offer the code to extend chmod in a small way. My 
extension don’t affect referenced file of symbolic links, just avoid them 
silent.

I need this ability, because I have a problem like this: Some times we need to 
change mode of files in a directory recursively with root privilege. For 
example, the directory “/opt/xxxx”, I have installed many files in the 
directory, and files have different owner and mode. Some mode and owner of 
files are wrong, so I need to fix them by a program with root privilege. For 
security reason, we don’t want to affect files not in that directory, like 
“/etc/passwd”. Then, I found ‘-h’ parameter in “chown”, it help me to protect 
“/etc/passwd”, but in “chmod”, there is not similar parameter not to 
dereference symbolic links.

The patch is to provide “-h” in chmod, it works similar to it in “chown”. If 
the object file is a symbolic link, chmod skip it, and move to next file with 
“-h”. parameter.

Because my system is ubuntu 22.04, it can not install vc-dwim. I have to make 
the patch by git directly.

Currently chmod(1) will not traverse or operate on symlinks it encounters
when recursively traversing a hierarchy.
I.e. `chmod -R ... /opt/xxxx` would be fine for you
(assuming xxxx was not a symlink itself).

So we only need to consider the less usual case or passing
symlinks as command line parameters here.
However command line parameters can be filtered for symlinks
before being passed to chmod(1), so we're not really adding
more functionality to a shell environment at least.
For example one could:

  find /opt/xxxx \! -type l -print0 | xargs -r0 chmod ...

If we were to add this functionality to chmod(1)
it may be better to separate dir and non-dir command line param handling
though -H,-L,-P and -h, to be more consistent with other tools.

Given the points above I'm not sure if this is warranted.
chmod has had many suggestions previously to incorporate selection
internally, but was deemed more appropriately handled externally:
https://www.gnu.org/software/coreutils/rejected_requests.html#chmod

cheers,
Pádraig



reply via email to

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