[opensuse] Permission problem - I need another pair of eyes.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In a nutshell: cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ cer-g@Isengard:/data/My_Book/Fusion/Videos> pwd /data/My_Book/Fusion/Videos cer-g@Isengard:/data/My_Book/Fusion/Videos> whoami cer-g cer-g@Isengard:/data/My_Book/Fusion/Videos> groups users cer cer-g@Isengard:/data/My_Book/Fusion/Videos> cer-g@Isengard:/data/My_Book/Fusion> l total 12 drwxr-xr-x 3 cer cer 28 Jul 20 2018 ./ drwxr-xr-x 4 root root 34 Nov 3 18:29 ../ drwxrwxr-T+ 52 cer cer 8192 Apr 12 03:43 Videos/ cer-g@Isengard:/data/My_Book/Fusion> cer-g@Isengard:/data/My_Book/Fusion/Videos> mount | grep My /dev/mapper/cr_my_book on /data/My_Book type xfs (rw,nosuid,nodev,relatime,lazytime,attr2,inode64,noquota,user) cer-g@Isengard:/data/My_Book/Fusion/Videos> User "cer-g" is member of groups "users" and "cer" Directory has group permission "rwx" and is owned by "cer:cer" Same for parent directory. The user "cer-g" is denied access to the directory "Conviction/" and others. Why? I also have this: cer-g@Isengard:/data/My_Book/Fusion/Videos> getfacl Conviction # file: Conviction # owner: cer # group: cer # flags: --t user::rwx user:wwwrun:r-x group::--- mask::rwx other::r-- man getfacl says: Lines 5, 7 and 10 correspond to the user, group and other fields of the file mode permission bits. These three are called the base ACL entries. Lines 6 and 8 are named user and named group entries. Line 9 is the effective rights mask. This entry limits the effective rights granted to all groups and to named users. (The file owner and others permissions are not affected by the effective rights mask; all other entries are.) Lines 11--15 display the default ACL associated with this directory. Directories may have a default ACL. Regular files never have a default ACL. I'm a bit list here. My intention was to give user wwwrun read access (which it does have, apache works). But the line "group::---" confuses me. - -- Cheers Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXLDu4xwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVHX8AoJTG6pR9Y04Len/nOv3B G0CzH+WQAJwJCuu3RAvvQLdQDjAsNmKe2Pz2tQ== =Iaxt -----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 On Friday, 2019-04-12 at 22:02 +0200, Carlos E. R. wrote: El 2019-04-12 a las 22:02 +0200, Carlos E. R. escribió: In case of doubt, the machine runs Leap 15.0. The mail template I used to post has an outdated signature and I saw it too late. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHIEARECADIWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXLDvahQccm9iaW4ubGlz dGFzQGdteC5lcwAKCRC1MxgcbY1H1fxbAKCLN+QAH25lOEdgIqSDkHzrbuZdUQCg gh4L6RbJyybokS9q2+OgVwebRMs= =+tZp -----END PGP SIGNATURE-----
* Carlos E. R. <robin.listas@telefonica.net> [04-12-19 16:04]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
In a nutshell:
cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ cer-g@Isengard:/data/My_Book/Fusion/Videos> pwd /data/My_Book/Fusion/Videos cer-g@Isengard:/data/My_Book/Fusion/Videos> whoami cer-g cer-g@Isengard:/data/My_Book/Fusion/Videos> groups users cer cer-g@Isengard:/data/My_Book/Fusion/Videos>
cer-g@Isengard:/data/My_Book/Fusion> l total 12 drwxr-xr-x 3 cer cer 28 Jul 20 2018 ./ drwxr-xr-x 4 root root 34 Nov 3 18:29 ../ drwxrwxr-T+ 52 cer cer 8192 Apr 12 03:43 Videos/ cer-g@Isengard:/data/My_Book/Fusion>
cer-g@Isengard:/data/My_Book/Fusion/Videos> mount | grep My /dev/mapper/cr_my_book on /data/My_Book type xfs (rw,nosuid,nodev,relatime,lazytime,attr2,inode64,noquota,user) cer-g@Isengard:/data/My_Book/Fusion/Videos>
User "cer-g" is member of groups "users" and "cer"
Directory has group permission "rwx" and is owned by "cer:cer" Same for parent directory.
The user "cer-g" is denied access to the directory "Conviction/" and others.
Why?
I also have this:
cer-g@Isengard:/data/My_Book/Fusion/Videos> getfacl Conviction # file: Conviction # owner: cer # group: cer # flags: --t user::rwx user:wwwrun:r-x group::--- mask::rwx other::r--
man getfacl says:
Lines 5, 7 and 10 correspond to the user, group and other fields of the file mode permission bits. These three are called the base ACL entries. Lines 6 and 8 are named user and named group entries. Line 9 is the effective rights mask. This entry limits the effective rights granted to all groups and to named users. (The file owner and others permissions are not affected by the effective rights mask; all other entries are.) Lines 11--15 display the default ACL associated with this directory. Directories may have a default ACL. Regular files never have a default ACL.
I'm a bit list here. My intention was to give user wwwrun read access (which it does have, apache works).
But the line "group::---" confuses me.
- -- Cheers
Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE-----
iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXLDu4xwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVHX8AoJTG6pR9Y04Len/nOv3B G0CzH+WQAJwJCuu3RAvvQLdQDjAsNmKe2Pz2tQ== =Iaxt -----END PGP SIGNATURE-----
www and wwwrun are groups themselves. add user cer-g to wwwrun group. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 12 Apr 2019 16:15:31 -0400 Patrick Shanahan <paka@opensuse.org> wrote:
* Carlos E. R. <robin.listas@telefonica.net> [04-12-19 16:04]:
In a nutshell:
cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ [snip www and wwwrun are groups themselves. add user cer-g to wwwrun group.
But why? The directory belongs to group cer and gives all permissions to members and cer-g is a member of cer. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/04/2019 22.34, Dave Howorth wrote:
On Fri, 12 Apr 2019 16:15:31 -0400 Patrick Shanahan <> wrote:
* Carlos E. R. <> [04-12-19 16:04]:
In a nutshell:
cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ [snip www and wwwrun are groups themselves. add user cer-g to wwwrun group.
But why? The directory belongs to group cer and gives all permissions to members and cer-g is a member of cer.
Exactly. Unless the "T" plays some role I did not think about? man chmod: The letters rwxXst select file mode bits for the affected users: read (r), write (w), execute (or search for directories) (x), execute/search only if the file is a directory or already has execute permission for some user (X), set user or group ID on execution (s), restricted deletion flag or sticky bit (t). RESTRICTED DELETION FLAG OR STICKY BIT The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents unprivileged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp. For regular files on some older systems, the bit saves the program's text image on the swap device so it will load more quickly when run; this is called the sticky bit. I guess I can clear the sticky bit, I no longer need it. [...] cer@Isengard:/data/My_Book/Fusion/Videos> chmod -t Conviction/ cer@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ total 16 drwxrwxr--+ 3 cer cer 33 Jun 21 2017 ./ drwxrwxr-T+ 52 cer cer 8192 Apr 12 03:43 ../ drwxrwxr-T+ 2 cer cer 4096 Jun 22 2017 Temporada 1/ cer@Isengard:/data/My_Book/Fusion/Videos> cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> No, it is not it... -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 12/04/2019 22.34, Dave Howorth wrote:
On Fri, 12 Apr 2019 16:15:31 -0400 Patrick Shanahan <paka@opensuse.org> wrote:
* Carlos E. R. <robin.listas@telefonica.net> [04-12-19 16:04]:
In a nutshell:
cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ [snip www and wwwrun are groups themselves. add user cer-g to wwwrun group.
But why? The directory belongs to group cer and gives all permissions to members and cer-g is a member of cer.
I'm running fsck on it. Isengard:~ # mount | grep My /dev/mapper/cr_my_book on /data/My_Book type xfs (rw,nosuid,nodev,relatime,lazytime,attr2,inode64,noquota,user) Isengard:~ # umount -v /data/My_Book umount: /data/My_Book (/dev/mapper/cr_my_book) unmounted Isengard:~ # fsck /dev/mapper/cr_my_book fsck from util-linux 2.31.1 If you wish to check the consistency of an XFS filesystem or repair a damaged filesystem, see xfs_repair(8). Isengard:~ # man xfs_repair Isengard:~ # xfs_repair /dev/mapper/cr_my_book Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Isengard:~ # cer-g@Isengard:~> cd /data/My_Book/Fusion/Videos cer-g@Isengard:/data/My_Book/Fusion/Videos> cd Conviction/ -bash: cd: Conviction/: Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> No luck. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 12/04/2019 22.15, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [04-12-19 16:04]:
www and wwwrun are groups themselves. add user cer-g to wwwrun group.
Yes, that would give that user access to files with that ACL. But it does not explain the denied access as things are: drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ Why user cer-g that belongs to group "cer" can not access that directory? -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 12/04/2019 22.02, Carlos E. R. wrote:
In a nutshell:
cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ cer-g@Isengard:/data/My_Book/Fusion/Videos> pwd /data/My_Book/Fusion/Videos cer-g@Isengard:/data/My_Book/Fusion/Videos> whoami cer-g cer-g@Isengard:/data/My_Book/Fusion/Videos> groups users cer cer-g@Isengard:/data/My_Book/Fusion/Videos>
cer-g@Isengard:/data/My_Book/Fusion> l total 12 drwxr-xr-x 3 cer cer 28 Jul 20 2018 ./ drwxr-xr-x 4 root root 34 Nov 3 18:29 ../ drwxrwxr-T+ 52 cer cer 8192 Apr 12 03:43 Videos/ cer-g@Isengard:/data/My_Book/Fusion>
cer-g@Isengard:/data/My_Book/Fusion/Videos> mount | grep My /dev/mapper/cr_my_book on /data/My_Book type xfs (rw,nosuid,nodev,relatime,lazytime,attr2,inode64,noquota,user) cer-g@Isengard:/data/My_Book/Fusion/Videos>
User "cer-g" is member of groups "users" and "cer"
Directory has group permission "rwx" and is owned by "cer:cer" Same for parent directory.
The user "cer-g" is denied access to the directory "Conviction/" and others.
Why?
I tried ltrace on "cat Conviction". I know I can't cat a directory, but a trace on cd doesn't work because it is an internal bash command. However, instead of getting: cer-g@Isengard:/data/My_Book/Fusion/Videos> md p cer-g@Isengard:/data/My_Book/Fusion/Videos> cat p cat: p: Is a directory cer-g@Isengard:/data/My_Book/Fusion/Videos> but I get permission denied: cer-g@Isengard:/data/My_Book/Fusion/Videos> strace -o cat.strace cat Conviction/ cat: Conviction/: Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> less cat.strace This is it, but doesn't tell anything new: open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=330604, ...}) = 0 mmap(NULL, 330604, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc6e1b63000 close(3) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 31), ...}) = 0 openat(AT_FDCWD, "Conviction/", O_RDONLY) = -1 EACCES (Permission denied) write(2, "cat: ", 5) = 5 write(2, "Conviction/", 11) = 11 open("/usr/share/locale-langpack/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) I also tried ltrace: getpagesize() = 4096 strrchr("cat", '/') = nil setlocale(LC_ALL, "") = "en_US.UTF-8" bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale" textdomain("coreutils") = "coreutils" __cxa_atexit(0x557774d18d40, 0, 0x557774f1e1e8, 0x736c6974756572) = 0 getopt_long(2, 0x7fffb8768458, "benstuvAET", 0x557774f1dc40, nil) = -1 __fxstat(1, 1, 0x7fffb87682a0) = 0 open("Conviction/", 0, 037777402000) = -1 __errno_location() = 0x7fea58c8a480 __ctype_get_mb_cur_max() = 6 __errno_location() = 0x7fea58c8a480 error(0, 13, 0x557774d1c324, 0x557774f1e300) = 0 __fpending(0x7fea58a8e720, 1, 0x557774d18d40, 0x7fea58a8ed70) = 0 fileno(0x7fea58a8e720) = 1 __freading(0x7fea58a8e720, 1, 0x557774d18d40, 0x7fea58a8ed70) = 0 __freading(0x7fea58a8e720, 1, 4, 0x7fea58a8ed70) = 0 fflush(0x7fea58a8e720) = 0 fclose(0x7fea58a8e720) = 0 __fpending(0x7fea58a8e640, 0, 0x7fea58a898e0, 2880) = 0 fileno(0x7fea58a8e640) = 2 __freading(0x7fea58a8e640, 0, 0x7fea58a898e0, 2880) = 0 __freading(0x7fea58a8e640, 0, 2052, 2880) = 0 fflush(0x7fea58a8e640) = 0 fclose(0x7fea58a8e640) = 0 +++ exited (status 1) +++ I don't know if this tells somebody what is going on. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 4/12/2019 1:02 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
In a nutshell:
cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/
So for user 'cer' and group 'cer' have access: 'rwx', but other has access 'r-- on a directory. That means noone should be able to look for objects in the directory, but dos allow reading the directory -- never quite sure about exactly what that would give in permissions, but I'd turn on the 'x' bit along with the 'r' bit on a directory, like: chmod o+rx Conviction Is that the prob you were looking for? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/04/2019 03.57, L A Walsh wrote:
On 4/12/2019 1:02 PM, Carlos E. R. wrote:
In a nutshell:
cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/
So for user 'cer' and group 'cer' have access: 'rwx', but other has access 'r-- on a directory. That means noone should be able to look for objects in the directory,
noone except cer and members of the group cer, and cer-g is a member of that group, yet has not access.
but dos allow reading the directory -- never quite sure about exactly what that would give in permissions, but I'd turn on the 'x' bit along with the 'r' bit on a directory, like:
chmod o+rx Conviction
Is that the prob you were looking for?
No, but does not work: cer@Isengard:/data/My_Book/Fusion/Videos> chmod o+rx Conviction cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-x+ 3 cer cer 33 Jun 21 2017 Conviction/ cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos> Tomorrow I will update that machine and reboot it, and see. This is absurd. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 4/12/2019 7:05 PM, Carlos E. R. wrote:
Is that the prob you were looking for?
No, but does not work:
cer@Isengard:/data/My_Book/Fusion/Videos> chmod o+rx Conviction
cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-x+ 3 cer cer 33 Jun 21 2017 Conviction/ cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos>
Can root access it? What type of file system? as far as you know, are there acls on the dir or just standard perm bitS? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 4/12/2019 7:41 PM, L A Walsh wrote:
as far as you know, are there acls on the dir or just standard perm bitS?
Just reviewed basenote. That g::--- appears odd. Does it deny access to '*' group(s). I.e. if user is a member of any other group then they are denied access? not sure how that would get there though. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/04/2019 04.41, L A Walsh wrote:
On 4/12/2019 7:05 PM, Carlos E. R. wrote:
Is that the prob you were looking for?
No, but does not work:
cer@Isengard:/data/My_Book/Fusion/Videos> chmod o+rx Conviction
cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-x+ 3 cer cer 33 Jun 21 2017 Conviction/ cer-g@Isengard:/data/My_Book/Fusion/Videos> l Conviction/ ls: cannot open directory 'Conviction/': Permission denied cer-g@Isengard:/data/My_Book/Fusion/Videos>
Can root access Certainly. And user 'cer'
What type of file system?
XFS - there is a post where I run xfsrepair on it :-)
as far as you know, are there acls on the dir or just standard perm bitS?
Yes, you can see them in the OP. On 13/04/2019 04.45, L A Walsh wrote:
Just reviewed basenote. That g::--- appears odd. Does it deny access to '*' group(s). I.e. if user is a member of any other group then they are denied access?
not sure how that would get there though.
Yes, I was thinking of that as I was brewing the morning tea :-) The thing is, I create the ACL like this: setfacl -m u:wwwrun:rx on newly created files. The files have these ACL: cer-g@Isengard:~/F_Videos/1_Almacenar> getfacl Conviction # file: Conviction # owner: cer-g # group: cer # flags: --t user::rwx user:wwwrun:r-x group::rwx <===== mask::rwx other::r-- Eventually, I copy the files over from one disk to another with rsync like this: cer@Isengard:~> time rsync --archive --acls --xattrs \ --hard-links --sparse --stats --human-readable \ --checksum /data/waterhoard/Fusion/Videos/1_Almacenar/ \ /data/My_Book/Fusion/Videos/ and the result is: cer-g@Isengard:~/F_Videos/1_Almacenar> cer-g@Isengard:~/F_Videos/3_MyBook_Videos> getfacl Conviction # file: Conviction # owner: cer # group: cer user::rwx user:wwwrun:r-x group::--- <==== mask::rwx other::r-- How has the ACL changed ? I told rsync to keep them. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
12.04.2019 23:02, Carlos E. R. пишет:
User "cer-g" is member of groups "users" and "cer"
Directory has group permission "rwx"
It does not.
and is owned by "cer:cer" Same for parent directory.
The user "cer-g" is denied access to the directory "Conviction/" and others.
Why?
File permissions deny access to members of file group.
I also have this:
cer-g@Isengard:/data/My_Book/Fusion/Videos> getfacl Conviction # file: Conviction # owner: cer # group: cer # flags: --t user::rwx user:wwwrun:r-x group::---
^^^^^^^^^^^^
mask::rwx other::r--
On 13/04/2019 06.46, Andrei Borzenkov wrote:
12.04.2019 23:02, Carlos E. R. пишет:
User "cer-g" is member of groups "users" and "cer"
Directory has group permission "rwx"
It does not.
No, group has "rwx". Group ACL as "---". I thought the main permissions had priority.
and is owned by "cer:cer" Same for parent directory.
The user "cer-g" is denied access to the directory "Conviction/" and others.
Why?
File permissions deny access to members of file group.
No, ACL permissions deny access.
I also have this:
cer-g@Isengard:/data/My_Book/Fusion/Videos> getfacl Conviction # file: Conviction # owner: cer # group: cer # flags: --t user::rwx user:wwwrun:r-x group::--- ^^^^^^^^^^^^ mask::rwx other::r--
Yes, I thought of that this morning, but it is not my doing. The command I used to set ACLSs was: setfacl -m u:wwwrun:rx The file was copied from another directory, by rsync. Original file: cer-g@Isengard:~/F_Videos/1_Almacenar> getfacl Conviction # file: Conviction # owner: cer-g # group: cer # flags: --t user::rwx user:wwwrun:r-x group::rwx <===== mask::rwx other::r-- copied file: cer-g@Isengard:~/F_Videos/1_Almacenar> cer-g@Isengard:~/F_Videos/3_MyBook_Videos> getfacl Conviction # file: Conviction # owner: cer # group: cer user::rwx user:wwwrun:r-x group::--- <==== mask::rwx other::r-- How has the ACL changed ? (the 't' I deleted yesterday) The command to copy the files was: cer@Isengard:~> time rsync --archive --acls --xattrs \ --hard-links --sparse --stats --human-readable \ --checksum /data/waterhoard/Fusion/Videos/1_Almacenar/ \ /data/My_Book/Fusion/Videos/ I told rsync to keep the ACLS, but it has modified them. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
13.04.2019 13:36, Carlos E. R. пишет:
On 13/04/2019 06.46, Andrei Borzenkov wrote:
12.04.2019 23:02, Carlos E. R. пишет:
User "cer-g" is member of groups "users" and "cer"
Directory has group permission "rwx"
It does not.
No, group has "rwx".
Sigh ... if you know everything why do you even ask in the first place? And if you ask, may be you can accept the fact that those who answer may actually know what they are talking about?
Group ACL as "---". I thought the main permissions had priority.
Read "man 5 acl", especially sections "CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS" and "ACCESS CHECK ALGORITHM".
and is owned by "cer:cer" Same for parent directory.
The user "cer-g" is denied access to the directory "Conviction/" and others.
Why?
File permissions deny access to members of file group.
No, ACL permissions deny access.
Sigh again ... they *are* permissions bits. The fact that ls displays ACL mask instead of group permissions does not change the fact that group permissions deny any access to group.
I also have this:
cer-g@Isengard:/data/My_Book/Fusion/Videos> getfacl Conviction # file: Conviction # owner: cer # group: cer # flags: --t user::rwx user:wwwrun:r-x group::--- ^^^^^^^^^^^^ mask::rwx other::r--
Yes, I thought of that this morning, but it is not my doing.
So what? You asked why you cannot access this directory and this is the answer.
The command I used to set ACLSs was:
setfacl -m u:wwwrun:rx
The file was copied from another directory, by rsync.
Original file:
cer-g@Isengard:~/F_Videos/1_Almacenar> getfacl Conviction # file: Conviction # owner: cer-g # group: cer # flags: --t user::rwx user:wwwrun:r-x group::rwx <===== mask::rwx other::r--
copied file:
cer-g@Isengard:~/F_Videos/1_Almacenar> cer-g@Isengard:~/F_Videos/3_MyBook_Videos> getfacl Conviction # file: Conviction # owner: cer # group: cer user::rwx user:wwwrun:r-x group::--- <==== mask::rwx other::r--
How has the ACL changed ?
ACL did not change. Group permissions changed. Trivial answer is umask. Less trivial answer is default ACL on parent directory. You are in the best position to debug it as only you can reproduce it in your environment.
(the 't' I deleted yesterday)
The command to copy the files was:
cer@Isengard:~> time rsync --archive --acls --xattrs \ --hard-links --sparse --stats --human-readable \ --checksum /data/waterhoard/Fusion/Videos/1_Almacenar/ \ /data/My_Book/Fusion/Videos/
I told rsync to keep the ACLS, but it has modified them.
On 13/04/2019 14.24, Andrei Borzenkov wrote:
13.04.2019 13:36, Carlos E. R. пишет:
...
Yes, I thought of that this morning, but it is not my doing.
So what? You asked why you cannot access this directory and this is the answer.
Sigh. You always have to be so blunt? It was not my doing, which explains why I did not understand what was going on. I had not written that permission. What my mind saw was the permissions I had written.
The command I used to set ACLSs was:
setfacl -m u:wwwrun:rx
The file was copied from another directory, by rsync.
Original file:
cer-g@Isengard:~/F_Videos/1_Almacenar> getfacl Conviction # file: Conviction # owner: cer-g # group: cer # flags: --t user::rwx user:wwwrun:r-x group::rwx <===== mask::rwx other::r--
copied file:
cer-g@Isengard:~/F_Videos/1_Almacenar> cer-g@Isengard:~/F_Videos/3_MyBook_Videos> getfacl Conviction # file: Conviction # owner: cer # group: cer user::rwx user:wwwrun:r-x group::--- <==== mask::rwx other::r--
How has the ACL changed ?
ACL did not change. Group permissions changed. Trivial answer is umask. Less trivial answer is default ACL on parent directory. You are in the best position to debug it as only you can reproduce it in your environment.
Sigh. The group permission did not change, as shown by "ls -l". The ACL group permission changed. And no, I still have no idea why rsync changed, or did not copy, the group ACL. Do you?
(the 't' I deleted yesterday)
The command to copy the files was:
cer@Isengard:~> time rsync --archive --acls --xattrs \ --hard-links --sparse --stats --human-readable \ --checksum /data/waterhoard/Fusion/Videos/1_Almacenar/ \ /data/My_Book/Fusion/Videos/
I told rsync to keep the ACLS, but it has modified them.
-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 4/13/2019 5:32 AM, Carlos E. R. wrote:
On 13/04/2019 14.24, Andrei Borzenkov wrote:
13.04.2019 13:36, Carlos E. R. пишет:
Yes, I thought of that this morning, but it is not my doing.
So what? You asked why you cannot access this directory and this is the answer.
Sigh. You always have to be so blunt?
==== Apparently. I gave you the same answer as Andrei, two hours earlier, but I phrased it in the form of an exploratory question and it got ignored: On 4/12/2019 7:45 PM, L A Walsh wrote:
Just reviewed basenote. That g::--- appears odd. Does it deny access to '*' group(s). I.e. if user is a member of any other group then they are denied access?
not sure how that would get there though.
================== Any people often wonder why they don't see more women contributing in technical fields -- maybe they just need to be more blunt? Of course when she is, there'll be hell to pay. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* L A Walsh <suse@tlinx.org> [04-13-19 16:15]:
On 4/13/2019 5:32 AM, Carlos E. R. wrote:
On 13/04/2019 14.24, Andrei Borzenkov wrote:
13.04.2019 13:36, Carlos E. R. пишет:
Yes, I thought of that this morning, but it is not my doing.
So what? You asked why you cannot access this directory and this is the answer.
Sigh. You always have to be so blunt?
==== Apparently. I gave you the same answer as Andrei, two hours earlier, but I phrased it in the form of an exploratory question and it got ignored:
On 4/12/2019 7:45 PM, L A Walsh wrote:
Just reviewed basenote. That g::--- appears odd. Does it deny access to '*' group(s). I.e. if user is a member of any other group then they are denied access?
not sure how that would get there though.
==================
Any people often wonder why they don't see more women contributing in technical fields -- maybe they just need to be more blunt? Of course when she is, there'll be hell to pay.
or SHE will use too many words :) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/04/2019 22.13, L A Walsh wrote:
On 4/13/2019 5:32 AM, Carlos E. R. wrote:
On 13/04/2019 14.24, Andrei Borzenkov wrote:
13.04.2019 13:36, Carlos E. R. пишет:
Yes, I thought of that this morning, but it is not my doing.
So what? You asked why you cannot access this directory and this is the answer.
Sigh. You always have to be so blunt?
==== Apparently. I gave you the same answer as Andrei, two hours earlier, but I phrased it in the form of an exploratory question and it got ignored:
On 4/12/2019 7:45 PM, L A Walsh wrote:
Just reviewed basenote. That g::--- appears odd. Does it deny access to '*' group(s). I.e. if user is a member of any other group then they are denied access?
not sure how that would get there though.
==================
Hey, I did not ignore it! I replied to it, but inside a reply to a previous post from you 5 minutes earlier. I combined my reply in just one post. I saw both yours and Andrei's when I switched on the machine in the morning, his was nearer the edge of the display and read it first. I did notice the ACLS were weird since my very first post. I said «But the line "group::---" confuses me». Those were not the ACLS permissions /I/ had wrote on the directory, they were different. And I thought that filesystem permissions had precedence over ACLS. So I posted hoping for comments. :-)
Any people often wonder why they don't see more women contributing in technical fields -- maybe they just need to be more blunt? Of course when she is, there'll be hell to pay.
I appreciate your posts, you often nail issues. So does Andrei, but he was so blunt that I ignored most of his post in anger. Anyway, the problem was caused by this command: cer@Isengard:~> time rsync --archive --acls --xattrs \ --hard-links --sparse --stats --human-readable \ --checksum /data/waterhoard/Fusion/Videos/1_Almacenar/ \ /data/My_Book/Fusion/Videos/ Notice that the process is run by "cer", and that I ask rsync to keep ACLS by using "--acls". The original directory had this set of permissions (says ls -l and getfacl): drwxrwxr-T+ 3 cer-g cer 33 Jun 21 2017 Conviction/ # file: Conviction # owner: cer-g # group: cer # flags: --t user::rwx user:wwwrun:r-x group::rwx <===== mask::rwx other::r-- and the copied directory instead had this set: drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ # file: Conviction # owner: cer # group: cer user::rwx user:wwwrun:r-x group::--- <==== mask::rwx other::r-- The user ownership changes from cer-g to cer because the process is run by cer. Group remains the same. Filesystem permission set remains the same, but ACL permissions change. flag 't' is lost on destination because the instant I took the "photo" I had already removed it. Yesterday it was there, so ignore that. Everything is the same, except this line: "group::rwx" changes to: "group::---" I changed that manually, and now I can access the directory. I still have to run a find query to do the same on the entire archive, but that will wait. Now, why does the ACL permission have priority over the filesystem permissions? How can they be different? And why did not rsync copy them? How can I get rsync to really copy them over faithfully? Andrei hints at "mask". I don't understand. With whatever mask, the filesystem permissions were transferred by rsync perfectly, but not the ACLS. Why? -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 4/13/2019 2:01 PM, Carlos E. R. wrote:
Now, why does the ACL permission have priority over the filesystem permissions? How can they be different?
Permissions usually are dealt with: 1) more specific permissions are usually give more weight than more general ones. 2) sometimes 'denies' are processed before 'permits' and the search stops on the 1st match encountered. 3) in some systems, ordering is sensitive because, again the search stops on the 1st match.
And why did not rsync copy them? How can I get rsync to really copy them over faithfully?
Are you wanting an incremental copy or a full copy. If 'full', why not use tar? if you want incremental, tar can support that too. I think you will find it is much faster. With rsync, I'd have to 'play' to see what works for the reasons you are running into.
Andrei hints at "mask". I don't understand. With whatever mask, the > filesystem permissions were transferred by rsync perfectly, but not the ACLS. Why?
What were the group permissions supposed to be? rwx? What are the umasks of the running processes -- both on side where rsync is run as well as where it is extracted. I.e. If the extracting site has a mask of 077, its possible rsync would consider that to be a hint that group perms should be excluded. Also -- the 'default/inherited acl' on the directory -- Is there one? Might that be adding to the mix, by starting with acls for child inodes from that one?
From the 'chacl' man page:
Changing the permission bits of a file will change the file access ACL settings (see chmod(1)). However, file creation mode masks (see umask(1)) will not affect the access ACL settings of files created using directory default ACLs. Too tired to write more right now... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/04/2019 01.03, L A Walsh wrote:
On 4/13/2019 2:01 PM, Carlos E. R. wrote:
Now, why does the ACL permission have priority over the filesystem permissions? How can they be different?
Permissions usually are dealt with: 1) more specific permissions are usually give more weight than more general ones.
2) sometimes 'denies' are processed before 'permits' and the search stops on the 1st match encountered.
3) in some systems, ordering is sensitive because, again the search stops on the 1st match.
I will have to think it over, I don't understand that :-)
And why did not rsync copy them? How can I get rsync to really copy them over faithfully?
Are you wanting an incremental copy or a full copy. If 'full', why not use tar?
No. I'm doing a plain file move in two steps, from one disk to another disk. First I copy the files, later I delete them. I do the copy with rsync because I thought it would do a *exact* copy and does checksums. (when the main disk gets full I move videos to the second disk, which is larger, and then create links on the first disk pointing to the videos on the second) (no, I'm not going to setup LVM)
Andrei hints at "mask". I don't understand. With whatever mask, the > filesystem permissions were transferred by rsync perfectly, but not the ACLS. Why?
What were the group permissions supposed to be? rwx?
Yes. And they are, look at "ls -l" output: cer-g@Isengard:/data/My_Book/Fusion/Videos> l | grep Conviction/ drwxrwxr-T+ 3 cer cer 33 Jun 21 2017 Conviction/ But on ACL they are "---" instead. And apparently, the ACL permissions supersede the filesystem permissions.
What are the umasks of the running processes -- both on side where rsync is run as well as where it is extracted.
I have no idea. I never look at that, nor change it. But: cer@Isengard:~> umask 0022 cer@Isengard:~>
I.e. If the extracting site has a mask of 077, its possible rsync would consider that to be a hint that group perms should be excluded.
It is the same computer, just across two separate disks. A single process AFAIK.
Also -- the 'default/inherited acl' on the directory -- Is there one?
I have no idea. If that's something I have to do manually, I did not. I don't know how to check it, or how to set it. There is a cronjob (by root, /etc/cron.daily/mio.videos) that is supposed to do: find /home/cer/Fusion/Videos/ -type d | \ parallel "chown cer:cer ''{}'' && \ chmod u+r+w+x,g+w+x,o+r-w-x,+t ''{}'' && \ chown cer-g:cer ''{}'' && \ setfacl -m u:wwwrun:rx ''{}'' " find /home/cer/Fusion/Videos/3_MyBook_Videos -type d | \ parallel "chown cer:cer ''{}'' && \ chmod u+r+w+x,g+w+x,o+r-w-x,+t ''{}'' && \ chown cer-g:cer ''{}'' && \ setfacl -m u:wwwrun:rx ''{}'' " But it has not run or has failed, because it should have set ownership of the directories to "cer-g" and it is still "cer". I'm not investigating that till I solve the current issue. I'll have to add to it set the ACL group permission, too.
Might that be adding to the mix, by starting with acls for child inodes from that one?
I'm afraid I don't understand.
From the 'chacl' man page:
Changing the permission bits of a file will change the file access ACL settings (see chmod(1)). However, file creation mode masks (see umask(1)) will not affect the access ACL settings of files created using directory default ACLs.
Too tired to write more right now...
Yeah, here is is 2 AM. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
participants (6)
-
Andrei Borzenkov -
Carlos E. R. -
Carlos E. R. -
Dave Howorth -
L A Walsh -
Patrick Shanahan