>>> chmod -R u+rwX,go-rwx /home/user/Documents
>>
>> I ran this command to restart the process :
>> find /home/user/Documents -type f -exec chmod u+rw,go-rwx -R {} \;
>> and will make executable all following files according the needs.
>
> More comments from me about the above. It is pretty good. It doesn't
> do anything bad. But it could be better.
>
> find $directory -type f
>
> That will find all files below the specified directory.
>
> -exec chmod u+rw,go-rwx -R {} \;
>
> That will chmod each file (each due to "{} \;") to the specified
> symbolic mode. All good.
>
> The -R is a little odd there. That says to recursively change files
> down a directory hierarchy. Of course the find is only going to pass
> it files so there won't ever be a directory seen. The -R in that case
> isn't doing any harm but neither is it doing anything at all. Also
> 'find' is already the super powerful nice recursive command. It is
> the biggest and best tool in the toolbox. Since recursive commands
> can get away from people sometimes I think it best to use one of them
> at a time. :-)
Yeah my bad. It was consecutive to a neuronal freeze at the moment,
completely independent of my will. ^^
> The "{} \;" part is the traditional way to do -exec and you will find
> it in many Unix text books forever. It has some disadvantages though.
> It invokes the command once for each file. That isn't as efficient as
> it could be. More than a decade ago find was enhanced to include the
> "{} +" construct as a new and better form of this. For one "+" isn't
> special to the shell and does not need to be escaped. That is good by
> itself. But "{} +" also invokes the command once and passes the
> entire argument list, or as much of the argument list as possible on
> the system (it is system dependent), to the command. Therefore it is
> much more efficient since it reduces the number of fork and exec calls
> and makes handling the large file lists more efficient.
>
> If we polish up your command just a tiny bit we have this:
>
> find /home/user/Documents -type f -exec chmod u+rw,go-rwx {} +
>
> Again, your original command is fine and got the job done. I just
> wanted to polish it up a small amount for next time.
Very nice ! It's the first time that I see this kind of notation and
does save a lot of time on big jobs.. A big lot. :)
>>> That is usually called UPG (User Private Group).
>>> ...
>>
>> After reading this, I actually found that :
>>
>> umask and level of security : The umask command be used for setting
>> different security levels as follows:
>>
>> umask value Security level Effective permission (directory)
>> 022 Permissive 755
>> 026 Moderate 751
>> 027 Moderate 750
>> 077 Severe 700
>>
>> in there :
>> http://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html
>
> I gave that a quick skim and that article seems factually accurate.
> However trying to assign human fuzzy names "Permissive, Moderate,
> Severe" to them is completely arbitrary and I disagree with the
> direction at that point. I would rather have features and
> capabilities line up with the particular goals to be accomplished.
>
> Because frankly I would say for "Severe" security that I would turn
> the power off! That would be severe! :-)
But efficient ! I tried that but I guess you didn't receive the message
I sent at the time.. :)
>> And I was planning to set a "severe" security plan. Based on the
>> thinking that I have 3 computers (that only I use) to run behind a box
>> and that I thought wiser to set them to the maximum security first, find
>> out what they will exchange in second and then update the permissions
>> accordingly, as I have very little impact on the box security.
>
> Given all of the above I think that is a reasonable plan. I can't
> argue with the direction of your thinking. But I also understand how
> these permissions work and how they interact. So I personally
> wouldn't be recommending "Severe". I recommend a UPG "umask 02" which
> isn't even an option from the above list. If you are a sole user on
> your own system then it doesn't really matter.
>
>> I then opted for the umask 077. I'm not sure if it's really justified
>> but it couldn't do no harm.. I guess. :)
As I like to experiment^^, I tried that, find on Linuxaria :
/etc/pam.d/common-session
/etc/pam.d/common-session-noninteractive
And in each of these files add the line:
session optional pam_umask.so umask=0077
modified to my needs.. I shouldn't have. :D
The system then didn't want to open any graphic session and I was unable
to find why. Even after removing those bad ideas from pam.d or moving
all the . files and directories from my home.
I reinstalled it. So it could do some harm.
> But for example if you share files by making tar files and sending
> them out then that "Severe" setting creates problems for others when
> they unpack the files and the settings are propagated to them. I
> wouldn't make a software release bundle that way for example. Also
> for example if you interacted with others through a version control
> server then permissions can leak through there too. Again it all
> depends upon what you are doing and how you are interacting with
> others. I am not saying you are doing any of those things but I think
> eventually you will want to share some files with someone and then you
> need to be aware of the file permissions. The old saying is right
> that the devil is in the details!
Anyway after reading that point, I then opted for a per directory policy
as I do have some files to share.
I kept the 0077 setting in the .bashrc file (which doesn't cause any
issue :) ) and changed the policy using the acl technique.
setfacl -d -m u::rwx,g::r-x,o::--- /home/user/Documents/scripts/
For example. And so on according to the type of directory I wish to
manage. It seems to work fine and is much more effective.
Thanks again !
--
One original thought is worth a thousand mindless quotings.
Le vrai n'est pas plus sûr que le probable.
Diogene Laerce
signature.asc
Description: OpenPGP digital signature
