Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #190499 > unrolled thread

File permission confusion [Debian 9.1 with MATE]

Back to article view | Back to linux.debian.user

Contents

  File permission confusion [Debian 9.1 with MATE] Richard Owlett <rowlett@cloud85.net> - 2018-01-01 12:30 +0100
    Re: File permission confusion [Debian 9.1 with MATE] Mark Fletcher <mark27q1@gmail.com> - 2018-01-01 12:40 +0100
    [ADDENDUM] File permission confusion [Debian 9.1 with MATE] Richard Owlett <rowlett@cloud85.net> - 2018-01-01 12:40 +0100
      Re: File permission confusion [Debian 9.1 with MATE] "Thomas Schmitt" <scdbackup@gmx.net> - 2018-01-01 13:10 +0100
        Re: File permission confusion [Debian 9.1 with MATE] Richard Owlett <rowlett@cloud85.net> - 2018-01-01 18:00 +0100
          Re: File permission confusion [Debian 9.1 with MATE] Dan Purgert <dan@djph.net> - 2018-01-01 19:30 +0100
            Re: File permission confusion [Debian 9.1 with MATE] <tomas@tuxteam.de> - 2018-01-01 19:40 +0100
              Re: File permission confusion [Debian 9.1 with MATE] Dan Purgert <dan@djph.net> - 2018-01-02 12:10 +0100
          Re: File permission confusion [Debian 9.1 with MATE] "Thomas Schmitt" <scdbackup@gmx.net> - 2018-01-01 19:40 +0100
            Re: File permission confusion [Debian 9.1 with MATE] Richard Owlett <rowlett@cloud85.net> - 2018-01-02 15:10 +0100
          Re: File permission confusion [Debian 9.1 with MATE] Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2018-01-02 13:40 +0100
            Re: File permission confusion [Debian 9.1 with MATE] Richard Owlett <rowlett@cloud85.net> - 2018-01-02 15:20 +0100
              Re: File permission confusion [Debian 9.1 with MATE] "Thomas Schmitt" <scdbackup@gmx.net> - 2018-01-02 16:40 +0100
                Re: File permission confusion [Debian 9.1 with MATE] Brian <ad44@cityscape.co.uk> - 2018-01-02 19:40 +0100
                  Re: File permission confusion [Debian 9.1 with MATE] Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-02 19:40 +0100
                    Re: File permission confusion [Debian 9.1 with MATE] Brian <ad44@cityscape.co.uk> - 2018-01-02 19:50 +0100
                      Re: File permission confusion [Debian 9.1 with MATE] Richard Owlett <rowlett@cloud85.net> - 2018-01-02 20:40 +0100
                        Re: File permission confusion [Debian 9.1 with MATE] Brian <ad44@cityscape.co.uk> - 2018-01-02 21:10 +0100
                          Re: File permission confusion [Debian 9.1 with MATE] Curt <curty@free.fr> - 2018-01-02 22:20 +0100
                    Re: File permission confusion [Debian 9.1 with MATE] Dan Purgert <dan@djph.net> - 2018-01-02 21:30 +0100
                      Re: File permission confusion [Debian 9.1 with MATE] Brian <ad44@cityscape.co.uk> - 2018-01-02 21:50 +0100
                        Re: File permission confusion [Debian 9.1 with MATE] Dan Purgert <dan@djph.net> - 2018-01-03 00:20 +0100
                  Re: File permission confusion [Debian 9.1 with MATE] "Thomas Schmitt" <scdbackup@gmx.net> - 2018-01-02 21:10 +0100
                    Re: File permission confusion [Debian 9.1 with MATE] Brian <ad44@cityscape.co.uk> - 2018-01-02 21:40 +0100
                  Re: File permission confusion [Debian 9.1 with MATE] Richard Hector <richard@walnut.gen.nz> - 2018-01-06 06:20 +0100
      Re: [ADDENDUM] File permission confusion [Debian 9.1 with MATE] Brian <ad44@cityscape.co.uk> - 2018-01-01 13:10 +0100
      Re: [ADDENDUM] File permission confusion [Debian 9.1 with MATE] Brian <ad44@cityscape.co.uk> - 2018-01-01 20:40 +0100
    Re: File permission confusion [Debian 9.1 with MATE] David Wright <deblis@lionunicorn.co.uk> - 2018-01-01 17:30 +0100
      Re: File permission confusion [Debian 9.1 with MATE] Richard Owlett <rowlett@cloud85.net> - 2018-01-01 18:30 +0100
        Re: File permission confusion [Debian 9.1 with MATE] Michael Stone <mstone@debian.org> - 2018-01-01 18:40 +0100
          Re: File permission confusion [Debian 9.1 with MATE] Richard Owlett <rowlett@cloud85.net> - 2018-01-01 18:50 +0100
            Re: File permission confusion [Debian 9.1 with MATE] Michael Stone <mstone@debian.org> - 2018-01-01 19:10 +0100
              Re: File permission confusion [Debian 9.1 with MATE] <tomas@tuxteam.de> - 2018-01-01 19:20 +0100
                Re: File permission confusion [Debian 9.1 with MATE] Michael Stone <mstone@debian.org> - 2018-01-01 19:40 +0100
                  Re: File permission confusion [Debian 9.1 with MATE] Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-02 15:30 +0100
                    Re: File permission confusion [Debian 9.1 with MATE] Michael Stone <mstone@debian.org> - 2018-01-02 23:50 +0100
            Re: File permission confusion [Debian 9.1 with MATE] <tomas@tuxteam.de> - 2018-01-01 19:20 +0100

Page 1 of 2  [1] 2  Next page →

#190499 — File permission confusion [Debian 9.1 with MATE]

As user "richard" I created 3 files.
I later wanted to protect them totally from accidental change.
For each file, I went to Properties->Permissions and changed Access for 
Owner, Group, and Others to "Read Only".
As user "richard" I was able to delete them with Caja.
*UNDESIRABLE*
As "root" I changed Owner and Group to "root" leaving Access for all as 
"Read Only".

User "richard" could still *DELETE THEM*!
"Read Only" evidently does not mean what it implies.

What's happening?
TIA

[toc] | [next] | [standalone]

#190500

On Mon, Jan 01, 2018 at 05:23:29AM -0600, Richard Owlett wrote:
> As user "richard" I created 3 files.
> I later wanted to protect them totally from accidental change.
> For each file, I went to Properties->Permissions and changed Access for
> Owner, Group, and Others to "Read Only".
> As user "richard" I was able to delete them with Caja.
> *UNDESIRABLE*
> As "root" I changed Owner and Group to "root" leaving Access for all as
> "Read Only".
> 
> User "richard" could still *DELETE THEM*!
> "Read Only" evidently does not mean what it implies.
> 
> What's happening?
> TIA
> 
BY any chance did user richard own the directory they were in? 

I think the logic here is that deleting a file involves writing to the 
directory the file is in, so if you have priveleges to (for example 
ownership of) the directory, yes you'd be able to delete it.

I'd further postulate that in your scenario when the file was owned by 
root but the directory was owned by richard, richard would not have been 
able to append to or shorten the file -- because that would have 
involved writing to the file which richard did not have permissions to 
do.

Mark

[toc] | [prev] | [next] | [standalone]

#190501 — [ADDENDUM] File permission confusion [Debian 9.1 with MATE]

On 01/01/2018 05:23 AM, Richard Owlett wrote:
> As user "richard" I created 3 files.
> I later wanted to protect them totally from accidental change.
> For each file, I went to Properties->Permissions and changed Access for
> Owner, Group, and Others to "Read Only".
> As user "richard" I was able to delete them with Caja.
> *UNDESIRABLE*
> As "root" I changed Owner and Group to "root" leaving Access for all as
> "Read Only".
>
> User "richard" could still *DELETE THEM*!
> "Read Only" evidently does not mean what it implies.
>
> What's happening?
> TIA

Logged into Debian as "richard" SeaMonkey was able to change contents of 
those files.

HELP!
That is EXACTLY what I was trying to prevent.

[toc] | [prev] | [next] | [standalone]

#190502

Hi,

Richard Owlett wrote:
> As user "richard" I was able to delete them with Caja.

To prevent renaming or deletion of a file, you need to prevent writing
to the directory which hosts it. (Actually you delete the "dirent", which
points to the inode. The inode gets deleted when its last dirent is gone
and no filedescriptor is open on it any more.)

You may prevent writing either by taking away w-permission for everybody
  chmod a-w directory
or by preventing users from removing files which they don't own
  chmod +t directory
But the superuser will probably be able to override both of this without
the prior need to change the directory permissions.

There is
  chattr +i file
with some filesystems. I dimly remember we had a discussion about its
effectiveness a while ago ...


> Logged into Debian as "richard" SeaMonkey was able to change contents of
> those files.

It is a usual strategy against softlink spoofing to rename or delete the
original file and to store the changed content as new file.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#190505

On 01/01/2018 06:01 AM, Thomas Schmitt wrote:
> Hi,
>
> Richard Owlett wrote:
>> As user "richard" I was able to delete them with Caja.
>
> To prevent renaming or deletion of a file, you need to prevent writing
> to the directory which hosts it. (Actually you delete the "dirent", which
> points to the inode. The inode gets deleted when its last dirent is gone
> and no filedescriptor is open on it any more.)
>
> You may prevent writing either by taking away w-permission for everybody
>   chmod a-w directory
> or by preventing users from removing files which they don't own
>   chmod +t directory
> But the superuser will probably be able to override both of this without
> the prior need to change the directory permissions.
>
> There is
>   chattr +i file
> with some filesystems. I dimly remember we had a discussion about its
> effectiveness a while ago ...
>
>
>> Logged into Debian as "richard" SeaMonkey was able to change contents of
>> those files.
>
> It is a usual strategy against softlink spoofing to rename or delete the
> original file and to store the changed content as new file.
>
>
> Have a nice day :)
>
> Thomas
>
>

Color me confused.
Using "ls- l ..." to track happened I used "chattr" and "chmod" on the 
same directory. Unsatisfactory.

I need a tutorial. Man pages are unsatisfactory. Sort of like giving 
someone a dictionary and expecting them to become competent writers.

I used "linux tutorial chmod chattr" [w/o quotes] in both DuckDuckGo and 
Google. Many were as much use as the dictionary. Many had "tutorial" in 
neither title nor content. Many discussed "chattr" or "chmod" with only 
a passing mention of the other. Can anyone point to tutorials which:
     cover both in a single article
                   or
     a single author with articles on both
                   or
     a single website with articles on both

Thank you.

[toc] | [prev] | [next] | [standalone]

#190513

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Owlett wrote:
> [...]
> I need a tutorial. Man pages are unsatisfactory. Sort of like giving 
> someone a dictionary and expecting them to become competent writers.

In brief:
chmod - change "mode" bits (i.e. read / write / execute) based on
whether a user is the owner, part of the owning group, or neither.  Skip
to `CHMOD' for more detail (or scroll down about 6-7 lines)

chattr - change "attribute" bits (i.e. make it immutable, only allow
appends, many other things - see the manpage for all possibilities).
Skip to `CHATTR' for more detail (or scroll down about 65-70  lines)


CHMOD:
The output of ls -l shows these mode bits in the leftmost column.  The
format is [directory flag] [owner permissions] [group permissions]
[other permissions]; for example "-rwxr-xr--" for a non-directory file
that

 - the owner can read from, write to, or execute
 - the owning group can read from, or execute
 - anyone else can read

Note that "write" permissions on a file only really comes into play when
you're messing with a file in an editor (e.g. vim, emacs, nano,
whatever).  It does not necessarily prevent one from doing something
like:

   -rw-r----- [...] somefile.txt
   $ mv anotherfile.txt somefile.txt

Because you're not modifying "the file", but rather its parent
directory.  It's a very, very fine distinction, to be sure.

For directories, it's a little more ... nuanced.  A directory with
"dwrxr-xrw-" for example means

 - the owner can read directory contents ("ls"), write new files to /
   delete old files from the directory, and execute (cd into) it.
 - the group can list the directory contents, cd into it; and (if
   file-level permissions allow) read files; the group CANNOT create new
   files, delete files, etc.
 - Everyone else can do absolutely nothing, since they're not allowed to
   execute any commands on the directory.

Now, there are also some "special" bits for chmod, such as the setuid /
setgid bit, or the sticky bit.

Setting the setuid / setgid bit on a file means that when an executable
file is run, it is run with the user (or group) permissions.  For
example, the ping command:

  -rwsr-xr-x 1 root root [...] /bin/ping

this means that ANYONE running the 'ping' command will invoke it with
the permissions of the owner (i.e. root), rather than whatever
permissions their user may have.  This is required as `ping' needs to
send (and receive) packets on a network interface (and only root can do
that).


The "Sticky Bit" is a file and directory flag that means pretty much the
same thing, but again, there is a fine distinction when set on a
directory.

 - files having the sticky bit can only be renamed / deleted by the
   owning person (user ID)
 - directories having the sticky bit can only be renamed / deleted by
   the owning person (user ID) OR the owner of the directory itself.

Note that root supercedes all of these restrictions - root can cd into
non-executable directories, root can alter files with the sticky bit
set, and so on.


CHATTR:
This one gets fun - and may be more what you're looking for in terms of
making the files "unchangeable by anyone".  

Instead of modes (permissions), attributes on the file are metadata that
tell the filesystem itself what is allowed to happen with a file, and
these supercede modes.

If you're coming from a Windows background, you'll probably recognize
the attributes:

 - Archive -- File was edited since last backup operation.  Include with
   the next backup run.
 - Hidden -- Hidden file, do not show in Windows Explorer / DOS `dir'
   command (unless option set).  Equivalent to a dotfile in Linux
 - System -- "Special" hidden file, do not show in Windows Explorer /
   DOS `dir' command (unless option set).  No real linux equivalent that
   I can think of.
 - Read-Only -- File cannot be altered, unless application *explicitly*
   asks (probably run by Administrator).  Linux equivalent is chattr +i
   (set file to be immutable).
 - Compressed - NTFS filesystem only.  "Compress filesystem to save
   space" or whatever it was.
 - Encrypted - file is encrypted by the file system on save (IIRC,
   NTFS-only)
 - Not Indexed - Tell Windows Search to not index the file / directory.


The chattr manpage lists out everything that it lets you do. There are
quite a number of options (14+ at a quick glance), some of which you'll
find correspond to the Windows / DOS ones above.

> I used "linux tutorial chmod chattr" [w/o quotes] in both DuckDuckGo and 
> Google. Many were as much use as the dictionary.

Nah, most (all) of those so-called tutorials completely fail at being
tutorials.  A dictionary at least always fulfills its stated function
(at least when considering words agreed upon as words, rather than
slang, etc.).

If anything, I'd bet the Arch wiki's page[1], coupled with any external
links (e.g. wikipedia) would be what kind of information you're after
(although, they may be a bit light on the "tutorial" aspect for you --
but I've yet to be led astray by their examples).


[1] https://wiki.archlinux.org/index.php/File_permissions_and_attributes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJaSnnCAAoJEI4R3fMSeaKBjGgH/iSOsNiGTlGd/WZCDoOuwC2O
wSEVhueHjYvDo/F/lbu02z7H2ppRS7uE9tmnnmTtdkHYRFdEK/IQWoCNH/1DZ3Lm
hhp/J7EP/98k7XCfN8XT/LEimEPNiDYl5HswqEmPHqCF8v4uIBrTa/3Zhv0smM8h
h+zTH1AkDLBq9QD5FcA4t0n5FVn7bluTLxMzzeojqUAzpThDIDhTl6NF63j3gFEC
aa8Vm4QNM1+RmUi+RhEQani7G1+XCrturFxAMsVTyoAHJDGFfDDc2jjnyCCF76EQ
1LdU33Vi59lErSvA+vzzkNqXbRUY+bMz7c+nTtW1AF21/rsm3PM7L41oeJDyeE0=
=32l8
-----END PGP SIGNATURE-----

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#190514

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jan 01, 2018 at 06:11:59PM -0000, Dan Purgert wrote:

[...]

> Note that "write" permissions on a file only really comes into play when
> you're messing with a file in an editor (e.g. vim, emacs, nano,
> whatever).  It does not necessarily prevent one from doing something
> like:
> 
>    -rw-r----- [...] somefile.txt
>    $ mv anotherfile.txt somefile.txt
> 
> Because you're not modifying "the file", but rather its parent
> directory.  It's a very, very fine distinction, to be sure.

And that's the point... a program "messing" with the file might
well choose to copy the file to some other name, modify that copy,
and then, at the end, remove the original and rename the new
version to the original name: this is actually a common pattern
to achieve some form of "atomicity": when you want either all
the changes "committed to disk" or none (in case of failure).

As long as the basic difference between a file and its "name"
(i.e. the directory entry "pointing" to the file) is not understood,
this fine difference between writing to the file and modifying
(e.g. deleting) the directory entry will seem mysterious.

Otherwise... nice tutorial.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpKfhoACgkQBcgs9XrR2kbJZACggJJacqgUGuj9Hc6tVjRzWycw
8t4An069sCaghVj3PynydUgoghliVEey
=88r8
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#190532

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<tomas@tuxteam.de> wrote:
>
> On Mon, Jan 01, 2018 at 06:11:59PM -0000, Dan Purgert wrote:
>
> [...]
>
>> Note that "write" permissions on a file only really comes into play when
>> you're messing with a file in an editor (e.g. vim, emacs, nano,
>> whatever).  It does not necessarily prevent one from doing something
>> like:
>> 
>>    -rw-r----- [...] somefile.txt
>>    $ mv anotherfile.txt somefile.txt
>> 
>> Because you're not modifying "the file", but rather its parent
>> directory.  It's a very, very fine distinction, to be sure.
>
> And that's the point... a program "messing" with the file might
> well choose to copy the file to some other name, modify that copy,
> and then, at the end, remove the original and rename the new
> version to the original name: this is actually a common pattern
> to achieve some form of "atomicity": when you want either all
> the changes "committed to disk" or none (in case of failure).

Exactly.  Though reading it again, it was a poor turn of phrase to have
said "messing" with the file. 

>
> As long as the basic difference between a file and its "name"
> (i.e. the directory entry "pointing" to the file) is not understood,
> this fine difference between writing to the file and modifying
> (e.g. deleting) the directory entry will seem mysterious.
>
> Otherwise... nice tutorial.

Thanks.  chmod and chattr actually have really nice manpages :)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJaS2X/AAoJEI4R3fMSeaKBeVMH/3iBKuZxMvXqrRuLPJOQuYzc
O3cGFeooD7UOcucbzCVbRCtE5hYxzYKa3+35V+DrjJ58GbZArTU7+Bp+kGoVn9+A
D+3LQl/SmjSW0mh3whciw+75mioaErVPkJlC2JNpqaQWPkTk9IDyGleodof+jEz3
dGZm/Kkxd1f6XEMkBtz1QuqXocBISJrXyKlmBLC+vJwBnQHxPMTpCiF+zNGbK1xw
6RtSqlwH0lbnCMQQU1Lp2A1KU0ku30O90lG6gmgYRZHoSGg0yBSltqSuV/VsHGQT
UNwPXwX2UdOsN/quYtwaaqhwITw5LhYj8ONumlbPvYuaO1cj7xBpu8lPDqgftK4=
=NxQ1
-----END PGP SIGNATURE-----

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#190516

Hi,

Richard Owlett
> I used "linux tutorial chmod chattr" [w/o quotes] in both DuckDuckGo and
> Google.

A general search topic would be "linux file permissions" and "chattr".

I can show you an example shell session on an ext4 filesystem.

I create a directory with a file and take away w-permissions:

  $ cd /home/thomas/test
  $ mkdir my_private_dir
  $ echo private_content >my_private_dir/my_private_file
  $ chmod a-w my_private_dir/my_private_file
  $ chmod a-w my_private_dir

Now normal users including myelf cannot change the file content and cannot
rename or remove the file

  $ echo new_content >my_private_dir/my_private_file
  bash: my_private_dir/my_private_file: Permission denied
  $ mv my_private_dir/my_private_file my_private_dir/renamed_private_file
  mv: cannot move ‘my_private_dir/my_private_file’ to ‘my_private_dir/renamed_private_file’: Permission denied
  $ rm my_private_dir/my_private_file
  rm: cannot remove ‘my_private_dir/my_private_file’: Permission denied

But the superuser can override this without needing to use chmod

  # cd /home/thomas/test
  # echo foul >> my_private_dir/my_private_file
  # cat my_private_dir/my_private_file
  private_content
  foul
  # mv my_private_dir/my_private_file my_private_dir/renamed_private_file
  # ls -l my_private_dir
  total 4
  -r--r--r-- 1 thomas thomas 21 Jan  1 18:58 renamed_private_file

Now comes "chattr +i". Only the superuser can apply it.
After restoring the old filename and content, i do:

  # chattr +i my_private_dir/my_private_file

This keeps even the superuser from spoiling the file

  # echo foul >> my_private_dir/my_private_file
  bash: my_private_dir/my_private_file: Permission denied
  # mv my_private_dir/my_private_file my_private_dir/renamed_private_file
  mv: cannot move ‘my_private_dir/my_private_file’ to ‘my_private_dir/renamed_private_file’: Operation not permitted

The protection does not depend on missing w-permissions of the directory:

  # chmod u+w my_private_dir
  # rm my_private_dir/my_private_file
  rm: cannot remove ‘my_private_dir/my_private_file’: Operation not permitted

or missing w-permissions of the file file:

  # chmod u+w my_private_dir/my_private_file
  chmod: changing permissions of ‘my_private_dir/my_private_file’: Operation not permitted

even if the superuser temporarily allows the change and them runs "chattr +i"
again:

  # chattr -i my_private_dir/my_private_file
  # chmod u+w my_private_dir/my_private_file
  # chattr +i my_private_dir/my_private_file
  # echo foul >> my_private_dir/my_private_file
  bash: my_private_dir/my_private_file: Permission denied

----------------------------------------------------------------------

I can of course not comment on what particular GUI tools do when they
promise the user to make something "Read-only".
(... or what systemd is willing to do for its clients ....)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#190539

On 01/01/2018 12:32 PM, Thomas Schmitt wrote:
> Hi,
>
> Richard Owlett
>> I used "linux tutorial chmod chattr" [w/o quotes] in both DuckDuckGo
>> and Google.
>
> A general search topic would be "linux file permissions" and "chattr".

I did a DuckDuckGo search adding "tutorial" and got what I had been 
aiming at with my original searches. Thanks.

>
> I can show you an example shell session on an ext4 filesystem.
>
> I create a directory with a file and take away w-permissions:
>
>   $ cd /home/thomas/test
>   $ mkdir my_private_dir
>   $ echo private_content >my_private_dir/my_private_file
>   $ chmod a-w my_private_dir/my_private_file
>   $ chmod a-w my_private_dir
>
> Now normal users including myelf cannot change the file content and
> cannot rename or remove the file

That is my goal. I think doing all but the last step, examining the 
result, doing the last step, examining that result, and examining the 
differences will be educational. I suspect there is an AHAAA moment in 
my future :}

I've not yet gone deeply enough in the material I've been given.
I believe I have a homework assignment. Retirement does create 
opportunities.

> [snipping prior to futher study study]
>
> I can of course not comment on what particular GUI tools do when they
> promise the user to make something "Read-only".
> (... or what systemd is willing to do for its clients ....)
>

Understood. You might add "How it will be interpreted by a Windows 
refugee :/
Thanks again.

>
> Have a nice day :)
>
> Thomas
>
>

[toc] | [prev] | [next] | [standalone]

#190535

On seg, 01 jan 2018, Richard Owlett wrote:
> I need a tutorial. Man pages are unsatisfactory. Sort of like giving  
> someone a dictionary and expecting them to become competent writers.

The file/directory permission, and the chmod command to set them are  
very old. Any book on Unix or Linux should cover them. I remember  
O'Reilly had several good books, but I cannot recommend any specific  
one right now.

As for chattr, the suggestion someone else made to forget about it by  
now is a good one. First get a good understanding of the basic  
permission system.


-- 
Eduardo M KALINOWSKI
eduardo@kalinowski.com.br

[toc] | [prev] | [next] | [standalone]

#190540

On 01/02/2018 06:33 AM, Eduardo M KALINOWSKI wrote:
> On seg, 01 jan 2018, Richard Owlett wrote:
>> I need a tutorial. Man pages are unsatisfactory. Sort of like giving
>> someone a dictionary and expecting them to become competent writers.
>
> The file/directory permission, and the chmod command to set them are
> very old. Any book on Unix or Linux should cover them. I remember
> O'Reilly had several good books, but I cannot recommend any specific one
> right now.
>
> As for chattr, the suggestion someone else made to forget about it by
> now is a good one. First get a good understanding of the basic
> permission system.
>
>

I suspect at least attempting to understand the differing goals of chmod 
and chattr could be valuable.

[toc] | [prev] | [next] | [standalone]

#190546

Hi,

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.

"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.


 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.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#190555

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?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#190556

On Tue, Jan 02, 2018 at 06:30:55PM +0000, Brian wrote:
> What *prevents* a user from destroying his own backup files?

Intelligence, or an air gap, or both.

[toc] | [prev] | [next] | [standalone]

#190557

On Tue 02 Jan 2018 at 13:34:16 -0500, Greg Wooledge wrote:

> On Tue, Jan 02, 2018 at 06:30:55PM +0000, Brian wrote:
> > What *prevents* a user from destroying his own backup files?
> 
> Intelligence, or an air gap, or both.

The same things which prevent him from destroying the original files?
Nothing to do with permissions or ACLs. You make Michael Stone's point
for him.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#190560

On 01/02/2018 12:41 PM, Brian wrote:
> On Tue 02 Jan 2018 at 13:34:16 -0500, Greg Wooledge wrote:
>
>> On Tue, Jan 02, 2018 at 06:30:55PM +0000, Brian wrote:
>>> What *prevents* a user from destroying his own backup files?
>>
>> Intelligence, or an air gap, or both.
>
> The same things which prevent him from destroying the original files?
> Nothing to do with permissions or ACLs. You make Michael Stone's point
> for him.
>

A question in lieu of a parable.
Would a resident of a 25th floor flat appreciate a railing on his balcony?

[toc] | [prev] | [next] | [standalone]

#190562

On Tue 02 Jan 2018 at 13:33:11 -0600, Richard Owlett wrote:

> On 01/02/2018 12:41 PM, Brian wrote:
> > On Tue 02 Jan 2018 at 13:34:16 -0500, Greg Wooledge wrote:
> > 
> > > On Tue, Jan 02, 2018 at 06:30:55PM +0000, Brian wrote:
> > > > What *prevents* a user from destroying his own backup files?
> > > 
> > > Intelligence, or an air gap, or both.
> > 
> > The same things which prevent him from destroying the original files?
> > Nothing to do with permissions or ACLs. You make Michael Stone's point
> > for him.
> > 
> 
> A question in lieu of a parable.
> Would a resident of a 25th floor flat appreciate a railing on his balcony?#

Indubitably he would. It doesn't destroy his freedom to throw himself
over it, though.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#190570

On 2018-01-02, Brian <ad44@cityscape.co.uk> wrote:
>> 
>> A question in lieu of a parable.
>> Would a resident of a 25th floor flat appreciate a railing on his balcony?#
>
> Indubitably he would. It doesn't destroy his freedom to throw himself
> over it, though.
>

All this talk reminds me of the collapse of the wave function in quantum
physics. Someone will now advise that tower dwellers in the know place
trampolines on the sidewalk beneath the appropriate windows to provide
both for railing failure and suicidal tendencies. At which point you
will rejoin that the former when falling from lethal heights can always
make sure to avoid the latter.

You cannot get around the human element no matter how many safeguards (or
instruments of measure) you put into place.

-- 
"An autobiography is only to be trusted when it reveals something disgraceful.
A man who gives a good account of himself is probably lying, since any life
when viewed from the inside is simply a series of defeats."
— George Orwell

[toc] | [prev] | [next] | [standalone]

#190564

Greg Wooledge wrote:
> On Tue, Jan 02, 2018 at 06:30:55PM +0000, Brian wrote:
>> What *prevents* a user from destroying his own backup files?
>
> Intelligence, or an air gap, or both.

More backups?


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web