William Case wrote:
Hi;
Don't waste time on explaining how permissions work. I have got that
right down to the kernel level.
I have a program that I suspect has a permissions bug. I have checked
dmesg and nothing is said about a permissions problem. Can I count on
dmesg ALWAYS being right. Or, is there another way to double check if a
program is getting hung up on an incorrect permission for a process and
what process it might be.
First off, any given program may not report errors. Error reporting is
up to the programmer (I'd sack any programmer working for me that
didn't do error reporting, but that's just me). Example:
int fd;
fd = open("/etc/fradleybard.conf", O_RDONLY);
if (fd < 0)
fprintf(stderr, "Can't open fradleybard.conf\n");
exit(1);
The "if (fd < 0)" and such is completely up to me. If I didn't include
it, you'd have no idea what went wrong and it wouldn't be in dmesg or
/var/log/messages. If it were an SELinux constraint violation, it might
show up in an SELinux audit log. Did you check audit.log for SELinux
issues? Also note that running in SELinux permissive mode is NOT the
same as running in SELinux disabled mode--there are some things that are
still blocked even in permissive mode. Not a lot, but some.
You might want to see if the program in question has a debug mode or
debug level you can set to make it more verbose about what it's doing.
If the process is hung up, try using "lsof" to get a list of the files
that process is opening and accessing.
lsof -p <process-id-of-program> OR
lsof -c /regular-expresssion-matching-command-name/
(e.g. "lsof -c /gnome.*/" would list all files opened by all commands
starting with "gnome"). Tack on a "-r n" to repeat the list every "n"
seconds until you CTRL-C the lsof process.
"strace"ing the program in question may also give you a clue as to what
the problem is.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks@xxxxxxxx -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- To understand recursion, you must first understand recursion. -
----------------------------------------------------------------------
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
