Diogene Laerce wrote:
> I have a strange behavior lately on my Deby. After a run of :
> chown user:user -R /home/user/Documents
> and :
> chmod 700 -R /home/user/Documents
Unfortunately that command was a mistake. That will set rwx for owner
on all files unconditionally. For directories that is fine. But that
is not correct for files. Only executables and executable scripts
should have the execute bit set upon them.
What you wanted to set was:
chmod -R u+rwX,go-rwx /home/user/Documents
The capital 'X' is the trick. The GNU chmod documentation on this says:
27.2.4 Conditional Executability
--------------------------------
There is one more special type of symbolic permission: if you use `X'
instead of `x', execute/search permission is affected only if the file
is a directory or already had execute permission.
For example, this mode:
a+X
gives all users permission to search directories, or to execute files if
anyone could execute them before.
But wait! There's more. If the permissions were set correctly in the
beginning and you just wanted to *remove* permissions from group and
other then I would simply remove permissions from group and other.
chmod -R go-rwx /home/user/Documents
But I wonder why you need to remove group permission? Are you not
using the Debian default of putting each user in their own group?
That is usually called UPG (User Private Group). You originally said:
If you want to verify what chmod is doing the GNU chmod command has
the -v extension. It will echo print what it is doing while it is
doing it. Adding the -v would show helpful information. For example:
$ chmod -v -R 700 junk
mode of `junk' retained as 0700 (rwx------)
mode of `junk/junk2' retained as 0700 (rwx------)
mode of `junk/junk2/file1' changed to 0700 (rwx------)
> chown user:user -R /home/user/Documents
And so that group should belong to the user. Most importantly that
group should belong *solely* to the user. No other users should be in
that group. Therefore the better thing to do is to keep the group
permissions when removing other permissions.
chmod -R o-rwx /home/user/Documents
Then you don't need to do anything more. That would correspond to a
user "umask 07" setting. better set "umask 07" or new files will be
created with permissions you are trying to avoid.
Personally I always use "umask 02" and then only add extra protection
to specific files and directories that I want.
And of course all of this is only important if you are operating on a
multiuser server that has other people logging into it as non-root.
(Root does not matter in either case. You can't protect yourself from
root.) If this is on your personal laptop and no one else logs in
then none of this matters aand I would stick with the Debian UPG
default along with the default "umask 02".
> I run :
> find /home/user/Documents ! -perm 0700
As Linux-fan correctly noted that skips files that match 0700
exactly. So that part is working correctly. What didn't work was the
chmod 700 part. But that was good because that isn't want you want to
do.
> But I still get a list of files like :
> .
> .
> .
> /home/user/Documents/administrative/passport (2).png
> /home/user/Documents/administrative/00IMG_0006.jpg
> /home/user/Documents/administrative/IMG_0016.jpg
> /home/user/Documents/administrative/visit.appart
> .
> .
> .
Looks like the chmod didn't happen. But that means you didn't
incorrectly make image files executable so I would count that as a win
not a loss.
> Then if I checked their rights with :
> ls -la /home/user/Documents/administrative
> They are anyway all well checked :
> -rw-------
Hmm... Looks like your chmod did not happen. I double checked that I
wasn't having a misunderstanding and replicated your setup in a test
case and it did chmod all of the files for me.
> Could someone have an idea of what is going on ? What should I believe ?
> The "find" command or the "ls" one ?
I believe you must have a typo somewhere. If you double check
everything you will find it. However! As I explained you do not want
to chmod 700 all of your files recursively. That would be bad. So
take it as a good miss and don't do it again.
Bob
Attachment:
signature.asc
Description: Digital signature