This is FC4. I don't think /sbin/hwclock is doing anything useful on my system. Anyone else seeing this?
[root@surrey ~]# hwclock --show [root@surrey ~]#
[root@surrey ~]# strace -s50 hwclock --show execve("/sbin/hwclock", ["hwclock", "--show"], [/* 25 vars */]) = 0 brk(0) = 0x8f4b000 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f0e000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=107489, ...}) = 0 old_mmap(NULL, 107489, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ef3000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\n\37[\0004\0\0\0\4\260\26\0\0\0\0\0004\0 \0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1489572, ...}) = 0 old_mmap(0x59d000, 1219548, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x59d000 old_mmap(0x6c1000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x124000) = 0x6c1000 old_mmap(0x6c5000, 7132, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x6c5000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef2000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ef26c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0x6c1000, 8192, PROT_READ) = 0 mprotect(0x599000, 4096, PROT_READ) = 0 munmap(0xb7ef3000, 107489) = 0 gettimeofday({1122614971, 844952}, NULL) = 0 socket(PF_NETLINK, SOCK_RAW, 9) = -1 EACCES (Permission denied) write(2, "Error - unable to connect to audit system\n", 42) = 42 exit_group(77) = ? [root@surrey ~]#
[root@surrey ~]# tail -3 /var/log/audit/audit.log type=AVC msg=audit(1122615217.619:4364333): avc: denied { create } for pid=7432 comm="hwclock" scontext=root:system_r:hwclock_t tcontext=root:system_r:hwclock_t tclass=netlink_audit_socket type=SYSCALL msg=audit(1122615217.619:4364333): arch=40000003 syscall=102 success=no exit=-13 a0=1 a1=bfb5cbc0 a2=80542e0 a3=599ca0 items=0 pid=7432 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hwclock" exe="/sbin/hwclock" type=SOCKETCALL msg=audit(1122615217.619:4364333): nargs=3 a0=10 a1=3 a2=9
[root@surrey ~]# service auditd status auditd (pid 1565) is running... [root@surrey ~]#
On Fri, Jul 29, 2005 at 03:37:11PM +1000, Norman Gaywood wrote:
This is FC4. I don't think /sbin/hwclock is doing anything useful on my system. Anyone else seeing this?
[root@surrey ~]# hwclock --show [root@surrey ~]#
You need to update to the latest version of util-linux: util-linux-2.12p-9.5 using yum update ideally,
On Fri, 29 Jul 2005 akonstam@trinity.edu wrote:
On Fri, Jul 29, 2005 at 03:37:11PM +1000, Norman Gaywood wrote:
This is FC4. I don't think /sbin/hwclock is doing anything useful on my system. Anyone else seeing this?
[root@surrey ~]# hwclock --show [root@surrey ~]#
You need to update to the latest version of util-linux: util-linux-2.12p-9.5 using yum update ideally,
I have util-linux-2.12p-9.7 and I'm seeing this issue. /var/log/audit/audit.log shos access to hwclock denied.
Am Fr, den 29.07.2005 schrieb Matthew Saltzman um 17:57:
On Fri, 29 Jul 2005 akonstam@trinity.edu wrote:
On Fri, Jul 29, 2005 at 03:37:11PM +1000, Norman Gaywood wrote:
This is FC4. I don't think /sbin/hwclock is doing anything useful on my system. Anyone else seeing this?
[root@surrey ~]# hwclock --show [root@surrey ~]#
You need to update to the latest version of util-linux: util-linux-2.12p-9.5 using yum update ideally,
I have util-linux-2.12p-9.7 and I'm seeing this issue. /var/log/audit/audit.log shos access to hwclock denied.
Matthew Saltzman
hwclock --show | cat
Does that help?
Alexander
At 6:06 PM +0200 7/29/05, Alexander Dalloz wrote:
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VcMe/mbxoV5FuWUhumpw"
Am Fr, den 29.07.2005 schrieb Matthew Saltzman um 17:57:
On Fri, 29 Jul 2005 akonstam@trinity.edu wrote:
On Fri, Jul 29, 2005 at 03:37:11PM +1000, Norman Gaywood wrote:
This is FC4. I don't think /sbin/hwclock is doing anything useful on my system. Anyone else seeing this?
[root@surrey ~]# hwclock --show [root@surrey ~]#
You need to update to the latest version of util-linux: util-linux-2.12p-9.5 using yum update ideally,
I have util-linux-2.12p-9.7 and I'm seeing this issue. /var/log/audit/audit.log shos access to hwclock denied.
Matthew Saltzmanhwclock --show | cat
Does that help?
If it does, why? Newbie me would have thought that command to be equivalent to the original command, even from a security standpoint. ____________________________________________________________________ TonyN.:' mailto:tonynelson@georgeanelson.com ' http://www.georgeanelson.com/
On Fri, 29 Jul 2005, Alexander Dalloz wrote:
Am Fr, den 29.07.2005 schrieb Matthew Saltzman um 17:57:
On Fri, 29 Jul 2005 akonstam@trinity.edu wrote:
On Fri, Jul 29, 2005 at 03:37:11PM +1000, Norman Gaywood wrote:
This is FC4. I don't think /sbin/hwclock is doing anything useful on my system. Anyone else seeing this?
[root@surrey ~]# hwclock --show [root@surrey ~]#
You need to update to the latest version of util-linux: util-linux-2.12p-9.5 using yum update ideally,
I have util-linux-2.12p-9.7 and I'm seeing this issue. /var/log/audit/audit.log shos access to hwclock denied.
Matthew Saltzmanhwclock --show | cat
Does that help?
No change. Why do you think it would?
Alexander
Am Fr, den 29.07.2005 schrieb Matthew Saltzman um 20:17:
hwclock --show | cat
Does that help?
No change. Why do you think it would?
Alexander
Matthew Saltzman
http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-overview
hwclock is in the list of daemons covered by the targeted policy. This means hwclock may or may not have control over the terminal. Though it seems this issue is a different one (on the German speaking Fedora list the cat pipe helped recently[1]).
Alexander
[1] https://www.redhat.com/archives/fedora-de-list/2005-June/msg00109.html
hwclock --show | cat
Does that help?
It did for me (newly-installed FC4 system on Dell Dimension, hwclock from util-linux-2.12p-9.5).
I notice also that:
(*) hwclock produces output if run from one of the virtual text consoles, but not if run from an xterm (unless piped to another command, as you describe above).
(*) /sbin/hwclock does not produce output, but if I copy /sbin/hwclock to, say, /root/hwclock, /root/hwclock produces output.
(*) If run as /sbin/hwclock, strace output indicates that the program makes a call to ioctl, which works in a text console but not in an xterm. If run as /root/hwclock, it doesn't make that call, and all is well.
No change. Why do you think it would?
I'm interested in the explanation as well -- why piping the output to another command makes a difference. A colleague also says "ask him whether he found this by accident or whether he knew it would work because of some deep understanding ...." So -- ?
http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-overview
hwclock is in the list of daemons covered by the targeted policy. This means hwclock may or may not have control over the terminal.
Would I be right in guessing that this explains why putting the executable in a different directory changes the results??
Though it seems this issue is a different one (on the German speaking Fedora list the cat pipe helped recently[1]).
Alexander
[1] https://www.redhat.com/archives/fedora-de-list/2005-June/msg00109.html
If only I read German!
-- blm
On Fri, 29 Jul 2005, Berna Massingill wrote:
hwclock --show | cat
Does that help?
It did for me (newly-installed FC4 system on Dell Dimension, hwclock from util-linux-2.12p-9.5).
I notice also that:
(*) hwclock produces output if run from one of the virtual text consoles, but not if run from an xterm (unless piped to another command, as you describe above).
Interesting. From a VC, running hwclock produces the message "cannot connect to audit system". From a gterm, no output at all.
Am Fr, den 29.07.2005 schrieb Berna Massingill um 21:53:
hwclock --show | cat
Does that help?
It did for me (newly-installed FC4 system on Dell Dimension, hwclock from util-linux-2.12p-9.5).
I notice also that:
(*) hwclock produces output if run from one of the virtual text consoles, but not if run from an xterm (unless piped to another command, as you describe above).
(*) /sbin/hwclock does not produce output, but if I copy /sbin/hwclock to, say, /root/hwclock, /root/hwclock produces output.
(*) If run as /sbin/hwclock, strace output indicates that the program makes a call to ioctl, which works in a text console but not in an xterm. If run as /root/hwclock, it doesn't make that call, and all is well.
Interesting. Maybe one of the SELinux gurus is willing to jump in an enlighten us mortals.
No change. Why do you think it would?
I'm interested in the explanation as well -- why piping the output to another command makes a difference. A colleague also says "ask him whether he found this by accident or whether he knew it would work because of some deep understanding ...." So -- ?
Fair question. I "know" it from
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150153
http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-overview
hwclock is in the list of daemons covered by the targeted policy. This means hwclock may or may not have control over the terminal.
Would I be right in guessing that this explains why putting the executable in a different directory changes the results??
Though it seems this issue is a different one (on the German speaking Fedora list the cat pipe helped recently[1]).
Alexander
[1] https://www.redhat.com/archives/fedora-de-list/2005-June/msg00109.html
If only I read German!
Should have been just a reference, as the thread too shows a strace output.
-- blm
Alexander
On Fri, Jul 29, 2005 at 11:39:41PM +0200, Alexander Dalloz wrote:
Am Fr, den 29.07.2005 schrieb Berna Massingill um 21:53:
> hwclock --show | cat > > Does that help?
It did for me (newly-installed FC4 system on Dell Dimension, hwclock from util-linux-2.12p-9.5).
[ snip ]
No change. Why do you think it would?
I'm interested in the explanation as well -- why piping the output to another command makes a difference. A colleague also says "ask him whether he found this by accident or whether he knew it would work because of some deep understanding ...." So -- ?
Fair question. I "know" it from
Aha.
I was puzzled for a bit about how selinux would come into things on my system, since I thought during installation I had said not to enable that, but in fact /etc/selinux/config had SELINUX=enforcing, and when I changed that to "permissive", hwclock began producing output when it didn't before.
This also explains the difference in behavior between my FC4 system and another one to which I have access -- the other system has SELINUX=disabled.
Perhaps this will be useful information to others on the list.
hwclock is in the list of daemons covered by the targeted policy. This means hwclock may or may not have control over the terminal.
Would I be right in guessing that this explains why putting the executable in a different directory changes the results??
Though it seems this issue is a different one (on the German speaking Fedora list the cat pipe helped recently[1]).
Alexander
[1] https://www.redhat.com/archives/fedora-de-list/2005-June/msg00109.html
If only I read German!
Should have been just a reference, as the thread too shows a strace output.
Fair enough.
-- blm
On Fri, 2005-07-29 at 23:39 +0200, Alexander Dalloz wrote:
Am Fr, den 29.07.2005 schrieb Berna Massingill um 21:53:
hwclock --show | cat
Does that help?
It did for me (newly-installed FC4 system on Dell Dimension, hwclock from util-linux-2.12p-9.5).
I notice also that:
(*) hwclock produces output if run from one of the virtual text consoles, but not if run from an xterm (unless piped to another command, as you describe above).
(*) /sbin/hwclock does not produce output, but if I copy /sbin/hwclock to, say, /root/hwclock, /root/hwclock produces output.
(*) If run as /sbin/hwclock, strace output indicates that the program makes a call to ioctl, which works in a text console but not in an xterm. If run as /root/hwclock, it doesn't make that call, and all is well.
Interesting. Maybe one of the SELinux gurus is willing to jump in an enlighten us mortals.
Just an FYI, but the selinux-policy-targeted package from updates-testing fixed this hwclock problem for me....
* Thu Jul 28 2005 Dan Walsh dwalsh@redhat.com 1.25.3-9 - Bump for FC4
* Thu Jul 28 2005 Dan Walsh dwalsh@redhat.com 1.25.3-8 - Fixes for cups, hwclock, system_passwd, samba_net
--Rob
On Mon, 1 Aug 2005, Robert Locke wrote:
On Fri, 2005-07-29 at 23:39 +0200, Alexander Dalloz wrote:
Am Fr, den 29.07.2005 schrieb Berna Massingill um 21:53:
> hwclock --show | cat > > Does that help?
It did for me (newly-installed FC4 system on Dell Dimension, hwclock from util-linux-2.12p-9.5).
I notice also that:
(*) hwclock produces output if run from one of the virtual text consoles, but not if run from an xterm (unless piped to another command, as you describe above).
(*) /sbin/hwclock does not produce output, but if I copy /sbin/hwclock to, say, /root/hwclock, /root/hwclock produces output.
(*) If run as /sbin/hwclock, strace output indicates that the program makes a call to ioctl, which works in a text console but not in an xterm. If run as /root/hwclock, it doesn't make that call, and all is well.
Interesting. Maybe one of the SELinux gurus is willing to jump in an enlighten us mortals.
Just an FYI, but the selinux-policy-targeted package from updates-testing fixed this hwclock problem for me....
- Thu Jul 28 2005 Dan Walsh dwalsh@redhat.com 1.25.3-9
- Bump for FC4
- Thu Jul 28 2005 Dan Walsh dwalsh@redhat.com 1.25.3-8
- Fixes for cups, hwclock, system_passwd, samba_net
Now "hwclock --show | cat" works, but "hwclock --show" does not (in a gterm and after "su").
On Fri, Jul 29, 2005 at 11:57:12AM -0400, Matthew Saltzman wrote:
On Fri, 29 Jul 2005 akonstam@trinity.edu wrote:
On Fri, Jul 29, 2005 at 03:37:11PM +1000, Norman Gaywood wrote:
This is FC4. I don't think /sbin/hwclock is doing anything useful on my system. Anyone else seeing this?
[root@surrey ~]# hwclock --show [root@surrey ~]#
You need to update to the latest version of util-linux: util-linux-2.12p-9.5 using yum update ideally,
I have util-linux-2.12p-9.7 and I'm seeing this issue. /var/log/audit/audit.log shos access to hwclock denied.
Since updating to util-linux-2.12p-9.7 (yum) my clock is off by 5 hours. Also /sbin/clock and /sbin/hwclock do nothing.
On Fri, 29 Jul 2005, teicah wrote:
On Fri, Jul 29, 2005 at 11:57:12AM -0400, Matthew Saltzman wrote:
On Fri, 29 Jul 2005 akonstam@trinity.edu wrote:
On Fri, Jul 29, 2005 at 03:37:11PM +1000, Norman Gaywood wrote:
This is FC4. I don't think /sbin/hwclock is doing anything useful on my system. Anyone else seeing this?
[root@surrey ~]# hwclock --show [root@surrey ~]#
You need to update to the latest version of util-linux: util-linux-2.12p-9.5 using yum update ideally,
I have util-linux-2.12p-9.7 and I'm seeing this issue. /var/log/audit/audit.log shos access to hwclock denied.
Since updating to util-linux-2.12p-9.7 (yum) my clock is off by 5 hours. Also /sbin/clock and /sbin/hwclock do nothing.
Are timezone settings correct? Is the UTC variable in /etc/sysconfig/clock set correctly? Is the HW clock set correctly (check the BIOS when rebooting)?
Norman Gaywood wrote:
This is FC4. I don't think /sbin/hwclock is doing anything useful on my system. Anyone else seeing this?
[root@surrey ~]# hwclock --show [root@surrey ~]#
I've seen this one too, on my selinux-enabled server-boxes. You could just temporarily put selinux in permissive mode, as a work-around: $ setenforce 0 $ hwclock --show $ setenforce 1
I haven't checked if any recent update has fixed this.
Øyvind.