So, to be clear, you su as the user hobbit and change to that directory and cannot read the file?
Sorry didn't read the original email..... Just ignore that question.
Is it just *this* user or *this* directory? Have you tried creating another user in the adm group or create another (unrelated) directory with the same rights? This is odd.
cheers, Phil.
On 3/29/2011 at 3:49 PM, in message <4D916BD1.2070709 at websitemanagers.com.au>, Adam Goryachev <adam at websitemanagers.com.au> wrote: On 29/03/2011 4:15 PM, Josh Luthman wrote: So (user) hobbit is in group adm
ll shows the file is owned by group adm
(user) hobbit can not read the file?
Yep, that's the problem.... (or at least, it has me befuddled)....
Thanks, Adam
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On 29/03/2011 4:51 PM, Phil Crooker wrote:
So, to be clear, you su as the user hobbit and change to that directory and cannot read the file?
Sorry didn't read the original email..... Just ignore that question.
Is it just *this* user or *this* directory? Have you tried creating another user in the adm group or create another (unrelated) directory with the same rights? This is odd. host:~# mkdir /blah host:~# cd /blah/ host:/blah# touch test host:/blah# chgrp adm test host:/blah# chmod 640 test host:/blah# ls -l total 0 -rw-r----- 1 root adm 0 2011-03-29 17:15 test host:/blah# su - hobbit hobbit at host:~$ cat /blah/test cat: /blah/test: Permission denied
Looks like any file in any directory has the same problem....
Thanks, Adam
Den 29-03-2011 08:17, Adam Goryachev skrev:
host:~# mkdir /blah host:~# cd /blah/ host:/blah# touch test host:/blah# chgrp adm test host:/blah# chmod 640 test host:/blah# ls -l total 0 -rw-r----- 1 root adm 0 2011-03-29 17:15 test host:/blah# su - hobbit hobbit at host:~$ cat /blah/test cat: /blah/test: Permission denied
Permissions on /blah ? Assuming the "hobbit" user is a member of group "adm", the /blah directory must have group "adm" and at least group-execute permissions. If group is not "adm", then execute permission for "all".
Regards, Henrik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/03/11 18:29, Henrik Størner wrote:
Den 29-03-2011 08:17, Adam Goryachev skrev:
host:~# mkdir /blah host:~# cd /blah/ host:/blah# touch test host:/blah# chgrp adm test host:/blah# chmod 640 test host:/blah# ls -l total 0 -rw-r----- 1 root adm 0 2011-03-29 17:15 test host:/blah# su - hobbit hobbit at host:~$ cat /blah/test cat: /blah/test: Permission denied
Permissions on /blah ? Assuming the "hobbit" user is a member of group "adm", the /blah directory must have group "adm" and at least group-execute permissions. If group is not "adm", then execute permission for "all".
In the above case, the directory was owner root, group root, permissions 655, so it wasn't a directory permission issue.
However, this still doesn't resolve or address the original issue of not being able to read /var/log/messages where I Showed the permissions of all the directories and files which *should* have allowed the user to read the file.
I'm sure there is something really bizarre going on for me, because this *should* work, and it can't be debian, because I'm sure there are plenty of other people out there running hobbit with debian who have this working properly....
Any other pointers? please? I really don't understand what else to look at...
Thanks, Adam
Adam Goryachev Website Managers Ph: +61 2 8304 0000 adam at websitemanagers.com.au Fax: +61 2 8304 0001 www.websitemanagers.com.au -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2TJWgACgkQGyoxogrTyiXjMwCbBe2yRkXfQs9kkAsV62RTdKtD WWEAoNS3GaLEH8CrSTPUI4YlpO9rrvOt =G6kp -----END PGP SIGNATURE-----
On 31/03/2011 10:42 AM, Jeremy Laidman wrote:
On Wed, Mar 30, 2011 at 11:43 PM, Adam Goryachev <adam at websitemanagers.com.au> wrote:
Any other pointers? please? I really don't understand what else to look at... Does "dmesg" show any kernel-level blocking (ACL, SELinux, AppArmor)? No, it doesn't :(
This really has me quite stumped... usually Linux has all the tools to make this sort of debug really simple, but strace and all simply show access denied, an I really don't understand why.
Regards, Adam
On 31/03/11 10:46 AM, Adam Goryachev wrote:
On 31/03/2011 10:42 AM, Jeremy Laidman wrote:
On Wed, Mar 30, 2011 at 11:43 PM, Adam Goryachev <adam at websitemanagers.com.au> wrote:
Any other pointers? please? I really don't understand what else to look at... Does "dmesg" show any kernel-level blocking (ACL, SELinux, AppArmor)? No, it doesn't :(
This really has me quite stumped... usually Linux has all the tools to make this sort of debug really simple, but strace and all simply show access denied, an I really don't understand why. Very mysterious.
Have you check the mount options, and try doing 'fsck' on the file system?
David.
Keep up to date with what's happening in Australian sport visit http://www.ausport.gov.au
This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.
On 31/03/2011 11:32 AM, David Baldwin wrote:
Have you check the mount options, and try doing 'fsck' on the file system?
sorry to say, but you win
The problem was that this is a NFS root system, ie, the entire filesystem is mounted via NFS, and the uid and gid of the hobbit user was different between the NFS client and the NFS server. However, during NFS file requests, only the UID/GID is transmitted or used to determine whether access is granted or denied...
Thank you all for your help on this, I had forgotten about this little peculiarity (NFS) as I'm so used to working on the systems all the time as if they are normal stand-alone systems...
Apologies for wasting everyone's time too...
Regards, Adam
On Wed, Mar 30, 2011 at 9:16 PM, Adam Goryachev <adam at websitemanagers.com.au
wrote:
On 31/03/2011 11:32 AM, David Baldwin wrote:
Have you check the mount options, and try doing 'fsck' on the file system?
sorry to say, but you win
The problem was that this is a NFS root system, ie, the entire filesystem is mounted via NFS, and the uid and gid of the hobbit user was different between the NFS client and the NFS server. However, during NFS file requests, only the UID/GID is transmitted or used to determine whether access is granted or denied...
Thank you all for your help on this, I had forgotten about this little peculiarity (NFS) as I'm so used to working on the systems all the time as if they are normal stand-alone systems...
Apologies for wasting everyone's time too...
No worries - now we know something else to watch out for... :)
Ralph Mitchell
On 3/30/2011 at 11:13 PM, in message <4D93256C.8080008 at websitemanagers.com.au>, Adam Goryachev <adam at websitemanagers.com.au> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/03/11 18:29, Henrik Størner wrote:
Den 29-03-2011 08:17, Adam Goryachev skrev:
host:~# mkdir /blah host:~# cd /blah/ host:/blah# touch test host:/blah# chgrp adm test host:/blah# chmod 640 test host:/blah# ls -l total 0 -rw-r----- 1 root adm 0 2011-03-29 17:15 test host:/blah# su - hobbit hobbit at host:~$ cat /blah/test cat: /blah/test: Permission denied
Permissions on /blah ? Assuming the "hobbit" user is a member of group "adm", the /blah directory must have group "adm" and at least group-execute permissions. If group is not "adm", then execute permission for "all".
In the above case, the directory was owner root, group root, permissions 655, so it wasn't a directory permission issue.
However, this still doesn't resolve or address the original issue of not being able to read /var/log/messages where I Showed the permissions of all the directories and files which *should* have allowed the user to read the file.
I'm sure there is something really bizarre going on for me, because this *should* work, and it can't be debian, because I'm sure there are plenty of other people out there running hobbit with debian who have this working properly....
Any other pointers? please? I really don't understand what else to look at...
Thanks, Adam
Your blah example doesn't work. You need to move /root/blah to / and retry.
For me, if I'm troubleshooting this sort of baffling issue, it is important to get something simple that works and then gradually add relevant factors till it doesn't. So, the reason I asked for this test is to determine if that account can access a directory and file other than /var/log/messages with just group permissions. If you can, then there is something going on either with the log directory or the messages file specifically. So, if you su as that user and can then read a file in /blah with just the group permissions (be sure to remove the world rights), then try copying that file to /var/log and see if the user can see it there. If it can, then there is something basically wrong with messages...
On 31/03/2011 11:17 AM, Phil Crooker wrote:
On 3/30/2011 at 11:13 PM, in message <4D93256C.8080008 at websitemanagers.com.au>, Adam Goryachev <adam at websitemanagers.com.au> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/03/11 18:29, Henrik Størner wrote:
Den 29-03-2011 08:17, Adam Goryachev skrev:
host:~# mkdir /blah host:~# cd /blah/ host:/blah# touch test host:/blah# chgrp adm test host:/blah# chmod 640 test host:/blah# ls -l total 0 -rw-r----- 1 root adm 0 2011-03-29 17:15 test host:/blah# su - hobbit hobbit at host:~$ cat /blah/test cat: /blah/test: Permission denied Permissions on /blah ? Assuming the "hobbit" user is a member of group "adm", the /blah directory must have group "adm" and at least group-execute permissions. If group is not "adm", then execute permission for "all". In the above case, the directory was owner root, group root, permissions 655, so it wasn't a directory permission issue.
However, this still doesn't resolve or address the original issue of not being able to read /var/log/messages where I Showed the permissions of all the directories and files which *should* have allowed the user to read the file.
I'm sure there is something really bizarre going on for me, because this *should* work, and it can't be debian, because I'm sure there are plenty of other people out there running hobbit with debian who have this working properly....
Any other pointers? please? I really don't understand what else to look at...
Thanks, Adam
Your blah example doesn't work. You need to move /root/blah to / and retry. I'm not sure what you mean, I was using /blah.... host:~# mkdir /blah host:~# ls -ld /blah drwxr-xr-x 2 root root 4096 Mar 31 11:23 /blah host:~# echo test > /blah/test host:~# chgrp adm /blah/test host:~# chmod 640 /blah/test host:~# ls -l /blah/test -rw-r----- 1 root adm 5 Mar 31 11:23 /blah/test host:~# cat /blah/test test host:~# su - hobbit hobbit at host:~$ cd /blah hobbit at host:/blah$ ls -la total 12 drwxr-xr-x 2 root root 4096 Mar 31 11:23 . drwxr-xr-x 25 root root 4096 Mar 31 11:23 .. -rw-r----- 1 root adm 5 Mar 31 11:23 test hobbit at host:/blah$ cat test cat: test: Permission denied hobbit at host:~$ id uid=110(hobbit) gid=110(hobbit) groups=0(root),4(adm),110(hobbit) hobbit at host:~$ logout host:~# chgrp testgroup /blah/test host:~# su - adamg adamg at host:~$ cat /blah/test cat: /blah/test: Permission denied adamg at host:~$ ls -l /blah/test -rw-r----- 1 root testgroup 5 Mar 31 11:23 /blah/test adamg at host:~$ id uid=500(adamg) gid=500(adamg) groups=500(adamg),1014(testgroup)
For me, if I'm troubleshooting this sort of baffling issue, it is important to get something simple that works and then gradually add relevant factors till it doesn't. So, the reason I asked for this test is to determine if that account can access a directory and file other than /var/log/messages with just group permissions. If you can, then there is something going on either with the log directory or the messages file specifically. So, if you su as that user and can then read a file in /blah with just the group permissions (be sure to remove the world rights), then try copying that file to /var/log and see if the user can see it there. If it can, then there is something basically wrong with messages... I'm not sure where to start from, none of these basics seem to be working....
Thanks for all the suggestions
Adam
participants (6)
-
adam@websitemanagers.com.au
-
david.baldwin@ausport.gov.au
-
henrik@hswn.dk
-
jlaidman@rebel-it.com.au
-
Phil.Crooker@orix.com.au
-
ralphmitchell@gmail.com