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 2 of 2 — ← Prev page 1 [2]

#190566

On Tue 02 Jan 2018 at 20:15:25 -0000, Dan Purgert wrote:

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

Care to put a figure on this to guard against determined users?

-- 
Brian.

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

#190574

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

Brian wrote:
> On Tue 02 Jan 2018 at 20:15:25 -0000, Dan Purgert wrote:
>
>> 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?
>
> Care to put a figure on this to guard against determined users?

42, and a bowl of petunias.


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

iQEcBAEBAgAGBQJaTBEHAAoJEI4R3fMSeaKBR/MH/RX60bgr8z88zE0FCfeTYxwX
TzsFpOAJxTbck0ERwvV8ziiEMNFUtfeRYv+8Nwi/ONXzr/V/WRdgRc5pnJ4bPozp
AAspfGxp5HZzpGoi9j1bdR7Be+7xTZc5K9WprzFx4bg/SRfG122Qomfzssgb5emJ
uylZTOHqjyLCt1cm6YqqbinaoUpNcDUPElQbGAFTmD7jbctNPk68ZRVztTnrtI6x
XtJvQKIdOrkMXIgtxVrEayVfczPpuClo5atZmtKAqLPtKWSSZb2suaNITD61qxJT
014MLeME2ZuxDr9sf914HJkW34NEuG+bOz1AU50MEORHXzBg3Bjt1bPXIY9k3Ss=
=Rld/
-----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]

#190561

Hi,

Brian wrote:
> What *prevents* a user from destroying his own backup files?

Having multiple backups. Some with long intervals between them and some
on write-once media.

Of course the user must recover from mental incapacity often enough to
produce and verify good backups and to restore spoiled files before doing
the next backups. Insofar "chmod -w" and "chattr +i" can help to keep the
overall user performance sufficient for the purpose.


Have a nice day :)

Thomas

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

#190565

On Tue 02 Jan 2018 at 21:03:09 +0100, Thomas Schmitt wrote:

> Brian wrote:
> > What *prevents* a user from destroying his own backup files?
> 
> Having multiple backups. Some with long intervals between them and some
> on write-once media.

   > Big fleas have little fleas upon their backs to bite 'em,
   > And little fleas have lesser fleas, and so, ad infinitum.

Where does it end?

> Of course the user must recover from mental incapacity often enough to
> produce and verify good backups and to restore spoiled files before doing
> the next backups. Insofar "chmod -w" and "chattr +i" can help to keep the
> overall user performance sufficient for the purpose.

chattr is another ball game and involves getting the co-operation of
another entity. An ordinary  user does not have access to the "+i"
option.

-- 
Brian.

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

#190711

[Multipart message — attachments visible in raw view] — view raw

On 03/01/18 07:30, Brian wrote:
>>  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?

Send them to someone who will keep them regardless of subsequent
requests to delete?

Richard

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

#190503 — Re: [ADDENDUM] File permission confusion [Debian 9.1 with MATE]

On Mon 01 Jan 2018 at 05:37:15 -0600, Richard Owlett wrote:

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

chattr(1).

-- 
Brian.

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

#190517 — Re: [ADDENDUM] File permission confusion [Debian 9.1 with MATE]

On Mon 01 Jan 2018 at 05:37:15 -0600, Richard Owlett wrote:

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

It's your house - you can do whatever you want in it. You can put labels
on bottles of wine which say "do not drink before February 2018". Then
you can ignore them! :). Life's like that.

You invite someone into your house; don't give them the key to your
drinks cupboard. "Drink only" for the owner. :)

You want to prevent yourself opening the cupboard? Either try to
exercise some self-control or hide the key somewhere you are likely to
forget about (not that you will and, in any case, thers's nothing a good
hammar cannot readjust).

Cease wanting to be nannied and cosseted by the OS and having your every
actions constrained by external agents. Debian lets you do what *you*
want in your home directory.

You've just deleted a file you desperately wanted to keep? Never mind,
Next time you might think more clearly.

-- 
Brian.

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

#190504

On Mon 01 Jan 2018 at 05:23:29 (-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".

No, you set the access to "Read Permission". Each bit grants a
permission (on the file itself; its directory has to be considered
separately).

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

If you read "Read Only" in Linux documentation you should consider
filing a bug against it. As for these "implications", you might be
assuming MSDOS semantics from your past experience.

Cheers,
David.

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

#190507

On 01/01/2018 10:23 AM, David Wright wrote:
> On Mon 01 Jan 2018 at 05:23:29 (-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".
>
> No, you set the access to "Read Permission". Each bit grants a
> permission (on the file itself; its directory has to be considered
> separately).
>
>> 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.
>
> If you read "Read Only" in Linux documentation you should consider
> filing a bug against it.

I wouldn't YET claim a bug against Linux.
I've been seriously considering one against Caja.
Under Caja's Properties->Permissions tab:
   1. Owner is given choice of "Read-only" or "Read and Write"
   2. Group is given choice of "Read-only" or "Read and Write" or "None"
   3. Other is given choice of "Read-only" or "Read and Write" or "None"

WHY should one with "Read-only" access be able to delete it?
The file system of all partitions of this machine is ext4.

> As for these "implications", you might be
> assuming MSDOS semantics from your past experience.

Prior to too many decades of M$ windows I was command line oriented 
using what ever ran a PDP-8 from paper tape, RSX-11M, an Intel 
development system for the 8080, a Commodore Personal Electronic 
Transactor (aka a PET ;), and later a personal CPM-80 system. All were 
inherently single user systems. I then did things the M$ way for about 
30 years ;{



>
> Cheers,
> David.
>
>

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

#190508

On Mon, Jan 01, 2018 at 11:28:37AM -0600, Richard Owlett wrote:
>WHY should one with "Read-only" access be able to delete it?

A number of people have already explained that the ability delete 
requires write permission on the directory containing the file. You 
don't seem to have acknowledged that. This is the only way the semantics 
make sense, or else a user would be able to create a file that the owner 
of the directory would not be able to get rid of. As someone else 
already posted, when you delete a file you're not really deleting the 
file--you're removing one of potentially many directory entries in one 
of potentially many directories. Most people can get by without knowing 
that, and acting as though the directory entry and the file are unique 
and related, but if you start trying to manipulate permissions it is 
important to understand what's actually going on.

Mike Stone

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

#190509

On 01/01/2018 11:34 AM, Michael Stone wrote:
> On Mon, Jan 01, 2018 at 11:28:37AM -0600, Richard Owlett wrote:
>> WHY should one with "Read-only" access be able to delete it?
>
> A number of people have already explained that the ability delete
> requires write permission on the directory containing the file. You
> don't seem to have acknowledged that. This is the only way the semantics
> make sense, or else a user would be able to create a file that the owner
> of the directory would not be able to get rid of. As someone else
> already posted, when you delete a file you're not really deleting the
> file--you're removing one of potentially many directory entries in one
> of potentially many directories. Most people can get by without knowing
> that, and acting as though the directory entry and the file are unique
> and related, but if you start trying to manipulate permissions it is
> important to understand what's actually going on.
>
> Mike Stone
>

It's one of those theory and ability to apply.
That's why I asked for pointer suitable tutorial.
[https://lists.debian.org/debian-user/2018/01/msg00008.html]

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

#190510

And forget chattr, it's just going to confuse things.

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

#190511

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

On Mon, Jan 01, 2018 at 01:01:50PM -0500, Michael Stone wrote:
> And forget chattr, it's just going to confuse things.

The nice thing about chattr is that you can protect the
file's directory entry (which one?) from being deleted.
But I agree that using chattr without having first
understood chmod is like using a circular saw without
having first mastered the screwdriver. Not recommended :-)

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

iEYEARECAAYFAlpKej8ACgkQBcgs9XrR2kYmOQCfRrEB4V318LVCQQDyFm7pSWW6
DKAAn1duJiG//ltHyQf6XcuPf/qASjXz
=sCnT
-----END PGP SIGNATURE-----

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

#190515

On Mon, Jan 01, 2018 at 07:13:19PM +0100, tomas@tuxteam.de wrote:
>The nice thing about chattr is that you can protect the
>file's directory entry (which one?) from being deleted.
>But I agree that using chattr without having first
>understood chmod is like using a circular saw without
>having first mastered the screwdriver. Not recommended :-)

It also requires superuser, so it isn't going to help at the user level.
There is nothing a user can do to *prevent* himself from destroying his 
own files, but simply removing write permission from the file & 
directory will keep it from happening accidentally (he could still put 
back write permission and delete/modify the file). 

Mike Stone

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

#190542

On Mon, Jan 01, 2018 at 01:29:46PM -0500, Michael Stone wrote:
> There is nothing a user can do to *prevent* himself from destroying his own
> files,

Actually, there is.  It's called making a backup.

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

#190571

On Tue, Jan 02, 2018 at 09:21:30AM -0500, Greg Wooledge wrote:
>On Mon, Jan 01, 2018 at 01:29:46PM -0500, Michael Stone wrote:
>> There is nothing a user can do to *prevent* himself from destroying his own
>> files,
>
>Actually, there is.  It's called making a backup.

No, that potentially allows him to get the files back after destroying 
them. Assuming the backup is good.

Mike Stone
>

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

#190512

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

On Mon, Jan 01, 2018 at 11:49:01AM -0600, Richard Owlett wrote:

[...]

> It's one of those theory and ability to apply.
> That's why I asked for pointer suitable tutorial.
> [https://lists.debian.org/debian-user/2018/01/msg00008.html]

Roughly in this order:

  https://en.wikipedia.org/wiki/Inode

(or why a "file itself" in unix is very different from the
"directory entry", which is just a kind of file name: an
idea very foreign to people coming from DOS, who can safely
identify a directory entry with a file). Read several times,
until it sinks :-)

Once you can answer questions like

 - what happens if you hardlink a file "foo" to a new name
   "bar", and then delete "foo"?

 - what happens in the above scenario if you instead do
   a softlink?

 - why can't you hardlink across file system boundaries?
   what about a soft link?

 - what happens if you hardlink "foo" to "bar" and then change
   "bar"'s permissions?

Once you have the relationships between file, inode and directory
entry straight in your head, the rest is comparatively easy:

 - https://en.wikipedia.org/wiki/Unix_filesystem
 - https://en.wikipedia.org/wiki/File_system_permissions

And yes, a man page is a manual, not a text book. So it's
as it is supposed to be :-)

A good introductory text (it's a bit old, the implementation
details have changed a lot since, but it'll give you a good
foundation) is Maurice Bach's "The design of the UNIX operating
system":

  https://archive.org/details/DesignOfTheUnixOperatingSystemByMauriceBach

oh, and leave a tip to the great folks at the Internet archive
on your way out.

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

iEYEARECAAYFAlpKeWkACgkQBcgs9XrR2ka+YQCfb6pd42nuPPZnyFe+6zhTnITd
vJEAnimui7UO4XLbrILugaUhzrvzFIX7
=qqgm
-----END PGP SIGNATURE-----

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web