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

Re: Getting rights right

>>>   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 :


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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: