[opensuse] File delete permissions.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. - -- Cheers Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlk5kDcACgkQtTMYHG2NR9Vq1QCggsSKNnySeBs+qBDnrMJ2duOD KKYAn1Dj+vi6dWVFjKaS6iwNgolheymw =0zPI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 guess you own the directory. -- Per Jessen, Zürich (21.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/08/2017 02:45 PM, Per Jessen wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 guess you own the directory.
I agree with Per, if you own the directory and have write perms to it you can delete any file there. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-06-08 20:45, Per Jessen wrote:
Carlos E. R. wrote:
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 guess you own the directory.
Yes. Is that the reason? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/08/2017 07:58 PM, Carlos E. R. wrote:
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 could change the directory permissions to 1777 (as '/tmp'), so only the owner of a file may delete it (or root, of course). The question is, how - i.e., by whom - files are added. If you add all files with uid:guid = 'cer-g:root', and the containing directory is also owned by that user and has the permisssions 0755, then user "cer" won't be able to remove the files either. Then no special bits are neccessary. Have a nice day, Berny -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJZOdCPAAoJEEZQLveWkXGVVDoH/jzefOKMtq7wnpV2N8c6Jek2 1iZ9UmsW5mUo1Ol45eHfwqkMVnnk5k/AdlCdjbZf6Af545C60L9ssxNR9Z83SWfI iIgbqfPJ/DtheiWnJVOmlEabCm2c2TIrHk66E++GCUn9FBK7+DA3DwFkMcBRfe7Z jF/frVs47Vx2LuCgk5pc5BmMw/r3x6ALQiwDBzEza0dgx8XeuUmDSxGE5KVFc+da 3XhSgjP6bYWIQz8YloB1ktFkbQa0D+nno5gnUYdLcjUeTVw/yh6uWN8nCw2jcL+0 ho0VpDlkHnyBvUgaFmZOlV8j8uXs0rQkp2x4/48RX+68/TeGZDFYgk3SRf7I81I= =aNZK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-06-09 00:32, Bernhard Voelker wrote:
On 06/08/2017 07:58 PM, Carlos E. R. wrote:
You could change the directory permissions to 1777 (as '/tmp'), so only the owner of a file may delete it (or root, of course).
Sticky bit to the directory?
The question is, how - i.e., by whom - files are added. If you add all files with uid:guid = 'cer-g:root', and the containing directory is also owned by that user and has the permisssions 0755, then user "cer" won't be able to remove the files either. Then no special bits are neccessary.
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. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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:
You could change the directory permissions to 1777 (as '/tmp'), so only the owner of a file may delete it (or root, of course).
Sticky bit to the directory?
The question is, how - i.e., by whom - files are added. If you add all files with uid:guid = 'cer-g:root', and the containing directory is also owned by that user and has the permisssions 0755, then user "cer" won't be able to remove the files either. Then no special bits are neccessary.
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). Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----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: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----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: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
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 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>
What is 'l'?
See? 'rm' doubts and asks. However, 'mc' doesn't ask and goes ahead, it happily deletes a file that is not mine.
Indeed:
mc -bash: mc: command not found
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!) That 'rm' asks, some (I don't mind it, easy to work around w/"-f") might consider "un-unix". Just like 'rm' used to be a depth-first tool, always processing children before parents, so "rm -fr --one-filesystem ." would safely delete all contents of a dir, but leave the dir (and leave other files systems alone). Now, it is incapable of doing that w/o fixes, patches.
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.
'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). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
L A Walsh composed on 2017-06-08 16:10 (UTC-0700):
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!) . https://en.wikipedia.org/wiki/File_manager#Orthodox_file_managers
Without mc, or an equivalent OFM, my migration from OS/2 to Linux would have been delayed many years or more. It's never to my recollection deleted anything I didn't direct it to delete. Not having any OFM, typical of rescue environments, is a huge usability handicap to me. It's the first app I check for in an alien OS environment. Absence of native OFM was one big reason why when Win95 was new that I never gave it a serious look. -- "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: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-06-09 01:10, L A Walsh wrote:
Carlos E. R. wrote:
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 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>
What is 'l'?
alias l='ls -alF' I did not create that, SuSE did.
See? 'rm' doubts and asks. However, 'mc' doesn't ask and goes ahead, it happily deletes a file that is not mine.
Indeed:
mc -bash: mc: command not found
What is 'mc'? (midnight commander?
Yes. Other file browser might do the same thing, I haven't tested.
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.
'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. :-( -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
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). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
-----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: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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). And mc has a "safe delete" option: Options -> Configuration... -> [x] Safe delete HTH, -dnh -- panic("aha1740.c"); /* Goodbye */ linux-2.2.16/drivers/scsi/aha1740.c -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
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: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-06-09 01:22, John Andersen wrote:
On 06/08/2017 10:58 AM, Carlos E. R. wrote:
Is there some way I can negate user "cer" permission to delete a file? No, not sticky, it doesn't work.
man chattr
What do I have to look in there? I have read that manual, it doesn't help if you don't say what specific think to look at. Maybe you refer to this: A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute. Well, this works, but needs root to set it. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 06/08/2017 06:16 PM, Carlos E. R. wrote:
Well, this works, but needs root to set it.
Or sudo needs to do it. But it is, as you stated, something you don't do all the time and you want to protect yourself from mistakes. so its just as easy and chown and a lot more fool-proof. -- After all is said and done, more is said than done.
On 2017-06-09 03:30, John Andersen wrote:
On 06/08/2017 06:16 PM, Carlos E. R. wrote:
Well, this works, but needs root to set it.
Or sudo needs to do it. But it is, as you stated, something you don't do all the time and you want to protect yourself from mistakes. so its just as easy and chown and a lot more fool-proof.
It is indeed. But there are no hints in "ls -l" output that there are other attributes in place: cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1> l p3.mpeg -rw-r--r-- 1 cer-g root 0 Jun 8 19:50 p3.mpeg cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1> lsattr p3.mpeg ----i----------- p3.mpeg cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1> I thought there was to be a '+' symbol :-? Maybe it is for... duh, I forgot the name. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On June 8, 2017 6:42:09 PM PDT, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2017-06-09 03:30, John Andersen wrote:
On 06/08/2017 06:16 PM, Carlos E. R. wrote:
Well, this works, but needs root to set it.
Or sudo needs to do it. But it is, as you stated, something you don't do all the time and you want to protect yourself from mistakes. so its just as easy and chown and a lot more fool-proof.
It is indeed. But there are no hints in "ls -l" output that there are other attributes in place:
cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1> l p3.mpeg -rw-r--r-- 1 cer-g root 0 Jun 8 19:50 p3.mpeg cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1> lsattr p3.mpeg ----i----------- p3.mpeg cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1>
I thought there was to be a '+' symbol :-? Maybe it is for... duh, I forgot the name.
man lsattr ;-) -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-06-09 03:53, John Andersen wrote:
On June 8, 2017 6:42:09 PM PDT, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2017-06-09 03:30, John Andersen wrote:
On 06/08/2017 06:16 PM, Carlos E. R. wrote:
Well, this works, but needs root to set it.
Or sudo needs to do it. But it is, as you stated, something you don't do all the time and you want to protect yourself from mistakes. so its just as easy and chown and a lot more fool-proof.
It is indeed. But there are no hints in "ls -l" output that there are other attributes in place:
cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1> l p3.mpeg -rw-r--r-- 1 cer-g root 0 Jun 8 19:50 p3.mpeg cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1> lsattr p3.mpeg ----i----------- p3.mpeg cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1>
I thought there was to be a '+' symbol :-? Maybe it is for... duh, I forgot the name.
man lsattr ;-)
You can see that I used lsattr above. What I say is that ls doesn't inform that there are other attributes that it doesn't display. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Hello, On Fri, 09 Jun 2017, Carlos E. R. wrote:
cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1> l p3.mpeg -rw-r--r-- 1 cer-g root 0 Jun 8 19:50 p3.mpeg cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1> lsattr p3.mpeg cer@Isengard:~/Fusion/Videos/Crossing Jordan/Temporada 1>
I thought there was to be a '+' symbol :-? Maybe it is for... duh, I forgot the name.
ACLs. man getfacl / man setfacl HTH, -dnh --
which camera is this? -- Marcus Meissner Marcus, this is my bug :) -- Stephan Kulow in https://bugzilla.novell.com/show_bug.cgi?id=217731
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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.
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)
participants (10)
-
Andrei Borzenkov -
Bernhard Voelker -
Carlos E. R. -
Carlos E. R. -
David Haller -
Felix Miata -
John Andersen -
Ken Schneider - openSUSE -
L A Walsh -
Per Jessen