File delete permissions.

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: File delete permissions.

Carlos E. R.-2
On 2017-06-09 21:52, L A Walsh wrote:

> Carlos E. R. wrote:
>>>    'w' applies to the content of the object it is set on, allowing
>>> write to _that_ object.  "Filenames" are 'content" inside a directory
>>> (filenames that point to their own content -- the content of the file).
>>>    
>>
>> So, I would have to change the permissions of the directory. I can't do
>> that. :-(
>>  
> ====
>    Why is that? (shared?): you might be able to access lists to
> accomplish similar, or if you have "root", you could set the immutable
> bit on
> the file (which won't allow you to change the file until you clear the
> immutable bit w/root).
I don't remember why I said that, but another program needs access to
those directories.

Anyway, I have a working solution, I commented on it on another post.
Yes, I do change some of the permissions of the directories.

--
Cheers / Saludos,

                Carlos E. R.
                (from 42.2 x86_64 "Malachite" at Telcontar)


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: File delete permissions.

Carlos E. R.-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Saturday, 2017-06-10 at 03:06 +0200, Carlos E. R. wrote:

> On 2017-06-09 21:52, L A Walsh wrote:
>> Carlos E. R. wrote:
>>>>    'w' applies to the content of the object it is set on, allowing
>>>> write to _that_ object.  "Filenames" are 'content" inside a directory
>>>> (filenames that point to their own content -- the content of the file).
>>>>
>>>
>>> So, I would have to change the permissions of the directory. I can't do
>>> that. :-(
>>>
>> ====
>>    Why is that? (shared?): you might be able to access lists to
>> accomplish similar, or if you have "root", you could set the immutable
>> bit on
>> the file (which won't allow you to change the file until you clear the
>> immutable bit w/root).
>
> I don't remember why I said that, but another program needs access to
> those directories.

Maybe because the directories can be created/recreated by the
application, and in that case, the protection is lost.

> Anyway, I have a working solution, I commented on it on another post.
> Yes, I do change some of the permissions of the directories.

- --
Cheers,
        Carlos E. R.
        (from 42.2 x86_64 "Malachite" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlk7UHcACgkQtTMYHG2NR9UhnACgmYqo3lMrA2TN+KCJSgYU/fRL
GUYAn36BRqjXTTWDGN7wiSgwJ2kgcEOz
=jOrA
-----END PGP SIGNATURE-----

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: File delete permissions.

Carlos E. R.-2
In reply to this post by David Haller-4
On 2017-06-10 02:34, David Haller wrote:
> Hello,
>
> On Thu, 08 Jun 2017, L A Walsh wrote:
>> What is 'mc'?  (midnight commander?  FWIW -- I don't have it installed,
>> as I found it too easily deleted files -- i.e. tried starting it, and
>> then quiting, but something I typed to 'quit' deleted files.  Ug.
>> unfriendly!)
>
> You must've pressed F8 (delete) instead of F10 (quit).

Still you have to press "yes" after that.

> And mc has a "safe delete" option:
>     Options -> Configuration... -> [x] Safe delete

Yes, I have seen it, but I don't know what it does.

--
Cheers / Saludos,

                Carlos E. R.
                (from 42.2 x86_64 "Malachite" at Telcontar)


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: File delete permissions.

Felix Miata-3
Carlos E. R. composed on 2017-06-10 19:19 (UTC+0200):

> David Haller wrote:
.
>> And mc has a "safe delete" option:
>>     Options -> Configuration... -> [x] Safe delete
.
> Yes, I have seen it, but I don't know what it does.
.
'safe delete' defaults to No when you press F8.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: File delete permissions.

Carlos E. R.-4
In reply to this post by Bernhard Voelker
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Delayed mail. I had to resend it, my ISP is playing tricks on me.

On Friday, 2017-06-09 at 12:11 +0200, Bernhard Voelker wrote:

> On 06/09/2017 03:02 AM, Carlos E. R. wrote:
>> On 2017-06-09 00:32, Bernhard Voelker wrote:
>>> On 06/08/2017 07:58 PM, Carlos E. R. wrote:


>> No, user "cer" owns the directory and creates the files. Later on, I
>> manually change (chown) finished files to "cer-g" with the idea that
>> they are not altered by accident.
>>
>> So, now the directory is sticky, owned by cer, and still 'mc' deletes
>> files owned by cer-g without question.
>
> If you manually chown the file later, you need to do this as root anyway.
> So you could just chown the directory to root.  After that, the 1777 permission
> on the directory would prevent the user 'cer' from removing files owned by
> 'cer-g'.
>
> This is exactly like /tmp: just try to remove a file owned by someone else
> (and with a non-root user, of course).


Must the directory be owned by root for this to work?

I don't like giving the directory to root and 'w' access to others.

Ah! Ok, the directory has to be owned by cer-g, not cer. Now it works



er@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 2> l
total 8041540
drwxrwxr-t 2 cer-g cer         4096 Jun  9 20:07 ./
drwxr-xr-x 4 cer   users         56 Jun  8 20:00 ../
- -rw-r--r-- 1 cer-g cer            0 Jun  9 20:07 m.mpeg
- -rw-r--r-- 1 cer   users          0 Jun  9 19:55 p.mpeg
cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 2>

Now 'mc' refuses to delete m.mpeg


So the solution is:

Change the permissions of the Videos directory tree with a script:

#!/bin/bash
find /home/cer/Fusion/Videos/ -type d -exec chmod
u+r+w+x,g+w+x,o+r-w-x,+t '{}' \;
find /home/cer/Fusion/Videos/ -type d -exec sudo chown cer-g:cer '{}' \;


Create a context menu on 'mc' so that I can switch ownership of
individual or multiple files:

+ t t
v       chown tagged files to cer-g
          for i in %t
          do
            sudo chown cer-g:cer "$i"
          done

+ t t
V       chown tagged files to cer
          for i in %t
          do
            sudo chown cer:cer "$i"
          done

+ ! t t
v       chown current file to cer-g
          sudo chown cer-g:cer "%f"

+ ! t t
V       chown current file to cer
          sudo chown cer:cer "%f"



The advantage to using attribute 'i' is that I can visually see which
files are "protected". Ok, not really protected, but suffices, I think.
I may create a script to also change the 'i' attribute of files owned by
cer-g.


- --
Cheers,
        Carlos E. R.
        (from 42.2 x86_64 "Malachite" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAllBFEIACgkQtTMYHG2NR9WWzwCeKpGKgvNsVTE1gtsZdnQGe+xm
l0EAnAww9lRIe3AnKJ9T+5HPtLcsEAKu
=RKGZ
-----END PGP SIGNATURE-----

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: File delete permissions.

Carlos E. R.-4
In reply to this post by Bernhard Voelker
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Delayed mail. I had to resend it, my ISP is playing tricks on me.

On Friday, 2017-06-09 at 12:11 +0200, Bernhard Voelker wrote:
> On 06/09/2017 03:02 AM, Carlos E. R. wrote:
>> On 2017-06-09 00:32, Bernhard Voelker wrote:
>>> On 06/08/2017 07:58 PM, Carlos E. R. wrote:


>> No, user "cer" owns the directory and creates the files. Later on, I
>> manually change (chown) finished files to "cer-g" with the idea that
>> they are not altered by accident.
>>
>> So, now the directory is sticky, owned by cer, and still 'mc' deletes
>> files owned by cer-g without question.
>
> If you manually chown the file later, you need to do this as root anyway.
> So you could just chown the directory to root.  After that, the 1777 permission
> on the directory would prevent the user 'cer' from removing files owned by
> 'cer-g'.
>
> This is exactly like /tmp: just try to remove a file owned by someone else
> (and with a non-root user, of course).

Let's see.

cer-g@Isengard:~> touch /tmp/test
cer-g@Isengard:~> logout
cer@Isengard:~> rm /tmp/test
rm: remove write-protected regular empty file '/tmp/test'? n
cer@Isengard:~>

And mc can't delete it either, so you are right.

The problem is, I do not control the directories, they are created by
another program (closed source). I don't know if it will create again
the directories or will have another issue with ownership. Might work,
though.

So, now I have two methods: your's, or the 'i' attribute.

I could probably chown the directory not to 'root', but to 'cer-g'

- --
Cheers,
        Carlos E. R.
        (from 42.2 x86_64 "Malachite" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAllBFYQACgkQtTMYHG2NR9U86ACfVKC8UhTX86tXMuDlgwfpA2XU
ZfwAn1pFwL1B8VTWCFiygjCAhypftnKD
=r3vd
-----END PGP SIGNATURE-----

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: File delete permissions.

Carlos E. R.-4
In reply to this post by Andrei Borzenkov

My ISP is playing tricks on me and blocking some posts of mine.
Resending with gmail, even if late.

On 2017-06-09 06:44, Andrei Borzenkov wrote:

> 08.06.2017 20:58, Carlos E. R. пишет:
>>
>> Hi,
>>
>> I'm user 'cer'. To avoid deleting by mistake some files, I changed their
>> ownership to another user:
>>
>> cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1> l p*mpeg
>> -rw-r--r-- 1 cer-g root 0 Jun  8 19:50 p.mpeg
>> -rw-r--r-- 1 cer-g root 0 Jun  8 19:50 p2.mpeg
>> -rw-r--r-- 1 cer-g root 0 Jun  8 19:50 p3.mpeg
>> -rw-r--r-- 1 cer-g root 0 Jun  8 19:50 p4.mpeg
>> cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1> rm p.mpeg
>> rm: remove write-protected regular empty file 'p.mpeg'? n
>> cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1>
>>
>>
>> See? 'rm' doubts and asks.
>> However, 'mc' doesn't ask and goes ahead, it happily deletes a file that
>> is not mine.
>>
>> I thought that the 'w' permission was needed to delete a file, but no.
>> Is there some way I can negate user "cer" permission to delete a file?
>> No, not sticky, it doesn't work.
>>
> You are asking wrong question. There is no file property that would
> magically cause *every program that tries to delete file* to ask you
> for confirmation. This is behavior of each individual program. Either mc
> can be configured to ask it or not.
>
> You certainly can "negate permission to delete a file" as you were
> already advised but then you will not able to delete file and you do not
> like it either nor is it what you want.
>
No, the 'i' attribute is certainly what I want. It is just that applying
it is a bit cumbersome, and 'ls -l' doesn't show it; thus when I'll try
to delete a file a year from now I will not remember why.



PS: Oh, now that I remember. Did you get my private post with the
vacation sites?

--
Cheers / Saludos,

                Carlos E. R.
                (from 42.2 x86_64 "Malachite" at Telcontar)



signature.asc (188 bytes) Download Attachment
12