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

Re: File permission confusion [Debian 9.1 with MATE]

On Tue 02 Jan 2018 at 16:31:15 +0100, Thomas Schmitt wrote:

> Richard Owlett wrote:
> > You might add "How it will be interpreted by a Windows refugee :/
> Keep in mind that the roots of our home are very old
>   https://en.wikipedia.org/wiki/File:Ken_Thompson_%28sitting%29_and_Dennis_Ritchie_at_PDP-11_%282876612463%29.jpg
> and that the rules made back then are still the base for operation.
> New layers have been added on top of them.
> > I suspect at least attempting to understand the differing goals of chmod and
> > chattr could be valuable.
> The concept of ownerships, of their manipulation by chmod, chown, chgrp,
> and of an allmighty superuser is part of the original layer.
> They accompany the concept of a file object ("inode") and directory entries
> ("dirent" or "hardlink") which have a name and refer to the nameless file
> object. This inode stores ownership, permissions, and file content. 
> Later came Access Control Lists (ACL, getfacl, setfacl) and ext2 file
> attributes (lsattr, chattr).
> ACL shall make permissions more finely adjustable than the three stage
> relationship model of owner, group members, and unprivileged others.

ACL is good stuff but it does not prevent a user from destroying or
altering files in his $HOME (the point which the OP raised).

> "chattr +i" shall enforce a read-only setting by keeping even the superuser
> from overriding it without prior lifting the ban by "chattr -i".
> Other chattr attributes may control or indicate filesystem specific features.

chattr is an external agency thing which has to be employed each time a
user wants to do something with his own files. I'll take the freedom to
look after my own $HOME.

>  Michael Stone wrote:
> > > There is nothing a user can do to *prevent* himself from destroying his
> > > own files,
> Greg Wooledge wrote:
> > Actually, there is.  It's called making a backup.
> This is a very good point.

What *prevents* a user from destroying his own backup files?


Reply to: