[opensuse] Who and why removes permissions to /dev/null ?
Hello, With opensuse-11.1 and kde4, I have seen three times on two different boxes that the mode of /dev/null was changed to 600. This breaks lots of scripts, which assume /dev/null is writable by anybody. The timestamp of /dev/null is also changed. Since chmod don't change the timestamp, this means the file is removed and recreated. When this happens, I see the following entries in /var/log/messages: Mar 6 15:03:16 raven polkit-grant-helper[13820]: granted authorization for org.freedesktop.packagekit.system-update to pid 4407 [uid=1000] [auth=root] Mar 6 15:03:22 raven shadow[14072]: default group changed - account=nobody, uid=65534, gid=65533, old gid=65533, by=0 M What is polkit-grant-helper and what kind of system-update is it doing? And why is it removing and recreating /dev/null? Any ideas? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Josef Wolf escribió:
Hello,
With opensuse-11.1 and kde4, I have seen three times on two different boxes that the mode of /dev/null was changed to 600. This breaks lots of scripts, which assume /dev/null is writable by anybody.
The timestamp of /dev/null is also changed. Since chmod don't change the timestamp, this means the file is removed and recreated.
try this: # auditctl -w /dev/null -p a # auditctl -e 1 and then watch the logs... if auditctl is not found, when you execute it as root, install package "audit" -- "If this is the best God can do, I am not impressed" -George Carlin (1937-2008) Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
On Fri, Mar 06, 2009 at 12:04:21PM -0300, Cristian Rodríguez wrote:
Josef Wolf escribió:
With opensuse-11.1 and kde4, I have seen three times on two different boxes that the mode of /dev/null was changed to 600. This breaks lots of scripts, which assume /dev/null is writable by anybody.
The timestamp of /dev/null is also changed. Since chmod don't change the timestamp, this means the file is removed and recreated.
try this:
# auditctl -w /dev/null -p a # auditctl -e 1
Done. Thanks for the suggestion. I'll have to wait now... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Josef Wolf escribió:
Done. Thanks for the suggestion. I'll have to wait now...
use "ausearch -f /dev/null" to get precise results of what is changing permissions of /dev/null -- "If this is the best God can do, I am not impressed" -George Carlin (1937-2008) Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-03-06 at 12:04 -0300, Cristian Rodríguez wrote:
The timestamp of /dev/null is also changed. Since chmod don't change the timestamp, this means the file is removed and recreated.
try this:
# auditctl -w /dev/null -p a # auditctl -e 1
and then watch the logs... if auditctl is not found, when you execute it as root, install package "audit"
Wow! You are a bag full of surprises. I'm storing this trick right away into my recipe file ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmxZIQACgkQtTMYHG2NR9XsXgCeJNPhMsEKWVFPSxkIsp4+NXcY lBUAoJfUj5OZ2nk8KWtlMcubKPG1PBVS =5nPV -----END PGP SIGNATURE-----
On Fri, Mar 06, 2009 at 03:48:55PM +0100, Josef Wolf wrote:
Hello,
With opensuse-11.1 and kde4, I have seen three times on two different boxes that the mode of /dev/null was changed to 600. This breaks lots of scripts, which assume /dev/null is writable by anybody.
The timestamp of /dev/null is also changed. Since chmod don't change the timestamp, this means the file is removed and recreated.
I think I found the guilty: it is the update of aaa_base. Check out the timestamp: raven:/var/log # ls -l --full-time /dev/null crw-rw-rw- 1 root root 1, 3 2009-03-06 15:03:22.680891742 +0100 /dev/null And then I found this in /var/log/pk_backend_zypp (I inserted whitespace to improve readability) 2009-03-06 15:03:19 <1> raven(13826) [zypp++] ExternalProgram.cc(start_program):210 Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--force' '--nodeps' '--' '/var/cache/zypp/packages/repo-update/rpm/x86_64/aaa_base-11.1-10007.14.1.x86_64.rpm' 2009-03-06 15:03:19 <1> raven(13826) [zypp++] ExternalProgram.cc(start_program):354 pid 13889 launched 2009-03-06 15:03:23 <1> raven(13826) [zypp++] ExternalProgram.cc(checkStatus):408 Pid 13889 successfully completed The question remains: why does this update remove and recreate /dev/null with wrong permissions? I have set umask to 0077 in /etc/bash.bashrc.local and used the updater applet in kde4. But IMHO the update should ignore this umask setting. Next question is: which files could be affected in addition? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Josef Wolf escribió:
I think I found the guilty: it is the update of aaa_base. Check out the timestamp:
No, we need to know exactly what executable did this, that was the reason I told you to try with audit, not be interpreting zypp log files. -- "If this is the best God can do, I am not impressed" -George Carlin (1937-2008) Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
Hello, On Sat, 07 Mar 2009, Josef Wolf wrote:
On Fri, Mar 06, 2009 at 03:48:55PM +0100, Josef Wolf wrote:
With opensuse-11.1 and kde4, I have seen three times on two different boxes that the mode of /dev/null was changed to 600. This breaks lots of scripts, which assume /dev/null is writable by anybody. [..] I think I found the guilty: it is the update of aaa_base. Check out the timestamp: [..] 2009-03-06 15:03:19 <1> raven(13826) [zypp++] ExternalProgram.cc(start_program):210 Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--force' '--nodeps' '--' '/var/cache/zypp/packages/repo-update/rpm/x86_64/aaa_base-11.1-10007.14.1.x86_64.rpm'
I don't think so. Or if so, it's a x86_64 problem: # ls -l /dev/null crw-rw-rw- 1 root root 1, 3 Dec 3 06:56 /dev/null # rpm -q --queryformat '%{name}-%{version}-%{release} %{installtime:date}\n' aaa_base aaa_base-11.1-10007.14.1 Wed Mar 4 18:57:41 2009 HTH, -dnh -- Bored? Want hours of entertainment? Just set the initdefault to 6! Whee! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, Mar 07, 2009 at 05:02:11PM +0100, David Haller wrote:
Hello,
On Sat, 07 Mar 2009, Josef Wolf wrote:
On Fri, Mar 06, 2009 at 03:48:55PM +0100, Josef Wolf wrote:
With opensuse-11.1 and kde4, I have seen three times on two different boxes that the mode of /dev/null was changed to 600. This breaks lots of scripts, which assume /dev/null is writable by anybody. [..] I think I found the guilty: it is the update of aaa_base. Check out the timestamp: [..] 2009-03-06 15:03:19 <1> raven(13826) [zypp++] ExternalProgram.cc(start_program):210 Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--force' '--nodeps' '--' '/var/cache/zypp/packages/repo-update/rpm/x86_64/aaa_base-11.1-10007.14.1.x86_64.rpm'
I don't think so. Or if so, it's a x86_64 problem:
# ls -l /dev/null crw-rw-rw- 1 root root 1, 3 Dec 3 06:56 /dev/null # rpm -q --queryformat '%{name}-%{version}-%{release} %{installtime:date}\n' aaa_base aaa_base-11.1-10007.14.1 Wed Mar 4 18:57:41 2009
I guess his modification of /etc/bash.bashrc.local and umask 077 is the issue. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 07 March 2009 19:21:23 Marcus Meissner wrote:
I guess his modification of /etc/bash.bashrc.local and umask 077 is the issue.
KERNEL=="null|zero|full|random|urandom", MODE="0666" It can't be the whole truth. It's supposed to be created by udev, and the above line is from an unmodified udev on 11.1 - it sets the mode explicitly. udev must also set the timestamp on the file, since on my machine it says 2008-12-03, which was long before this machine was installed. Something somewhere must have deleted and recreated /dev/null on that machine Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-03-07 at 19:33 +0100, Anders Johansson wrote:
On Saturday 07 March 2009 19:21:23 Marcus Meissner wrote:
I guess his modification of /etc/bash.bashrc.local and umask 077 is the issue.
KERNEL=="null|zero|full|random|urandom", MODE="0666"
It can't be the whole truth. It's supposed to be created by udev, and the above line is from an unmodified udev on 11.1 - it sets the mode explicitly. udev must also set the timestamp on the file, since on my machine it says 2008-12-03, which was long before this machine was installed.
Something somewhere must have deleted and recreated /dev/null on that machine
Rifgt. The file is dynamic, it is recreated on boot by udev. Therefore, something must be recreating it with wrong permissions. I would add those commands Cristian said to the script /etc/init.d/boot.local, and reboot. Then, if the file is changed, read the audit log. Otherwise, wait to see if it happens later. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmyw38ACgkQtTMYHG2NR9XOFQCfX8MPH6jNPdky6QdYUqLIICX2 hHoAn1fNLldKhbUD3DMXtsGEFlMECw2y =AKvQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hello, On Sat, 07 Mar 2009, Carlos E. R. wrote:
On Saturday, 2009-03-07 at 19:33 +0100, Anders Johansson wrote:
On Saturday 07 March 2009 19:21:23 Marcus Meissner wrote:
I guess his modification of /etc/bash.bashrc.local and umask 077 is the issue.
KERNEL=="null|zero|full|random|urandom", MODE="0666"
It can't be the whole truth. It's supposed to be created by udev, and the above line is from an unmodified udev on 11.1 - it sets the mode explicitly.
Does it? Is MODE in the udev rule the "wanted" rights (as in open(2)) or the "chmod"-to mode? The former would explain the result with a umask 077.
udev must also set the timestamp on the file, since on my machine it says 2008-12-03, which was long before this machine was installed.
Here: also 2008-12-03 which is post installation, pre upgrade from 10.2 to 11.1.
Something somewhere must have deleted and recreated /dev/null on that machine
Rifgt.
Aye. Udev. Josef, could you please mail the output of: grep null /lib/udev/rules.d/* /etc/udev/rules.d/* Maybe you have something weird there. -dnh, yet another reason for disliking automatisms in general and the whole udev, hal and dbus mishmash in particular. -- Diagnostic. n. Someone who doubts the existence of two Gods. -- Chris Suslowicz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 07 March 2009 22:49:51 David Haller wrote:
Does it? Is MODE in the udev rule the "wanted" rights (as in open(2)) or the "chmod"-to mode? The former would explain the result with a umask 077.
I don't think anyone has umask 000. It's certainly not the default. I haven't looked at the sources, but based on this, it can't use the umask Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
More comments, which I forgot On Saturday 07 March 2009 22:49:51 David Haller wrote:
Aye. Udev.
By the way, I don't think udev will ever remove anything
Josef, could you please mail the output of:
grep null /lib/udev/rules.d/* /etc/udev/rules.d/*
Maybe you have something weird there.
udev reacts to kernel events. A user can't normally trigger a kernel event to create the null device, it's hard coded in the kernel.
-dnh, yet another reason for disliking automatisms in general and the whole udev, hal and dbus mishmash in particular.
udev used to be a chaotic mess, but it's become a lot better in recent times hal, well, it makes sense to have some sort of abstraction layer for hardware. I don't know enough about other OSes to be able to comment on the alternatives, but there has to be something. I don't think dbus comes into it at all. It is an IPC system Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, Mar 07, 2009 at 10:49:51PM +0100, David Haller wrote:
Aye. Udev. Josef, could you please mail the output of:
grep null /lib/udev/rules.d/* /etc/udev/rules.d/*
raven:~ # grep null /lib/udev/rules.d/* /etc/udev/rules.d/* /lib/udev/rules.d/50-udev-default.rules:KERNEL=="null|zero|full|random|urandom", MODE="0666" /lib/udev/rules.d/50-udev-default.rules:KERNEL=="null", SYMLINK+="XOR" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 08 March 2009 12:25:13 Josef Wolf wrote:
On Sat, Mar 07, 2009 at 10:49:51PM +0100, David Haller wrote:
Aye. Udev. Josef, could you please mail the output of:
grep null /lib/udev/rules.d/* /etc/udev/rules.d/*
raven:~ # grep null /lib/udev/rules.d/* /etc/udev/rules.d/* /lib/udev/rules.d/50-udev-default.rules:KERNEL=="null|zero|full|random|uran dom", MODE="0666" /lib/udev/rules.d/50-udev-default.rules:KERNEL=="null", SYMLINK+="XOR"
Right. But this only gets triggered on boot. What you're looking for is something that deletes /dev/null and recreates it. udev cannot be responsible here Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, Mar 07, 2009 at 07:33:26PM +0100, Anders Johansson wrote:
On Saturday 07 March 2009 19:21:23 Marcus Meissner wrote:
I guess his modification of /etc/bash.bashrc.local and umask 077 is the issue.
KERNEL=="null|zero|full|random|urandom", MODE="0666"
Huh? Where should this line be? I don't seem to have such a line: raven:~ # find /etc/udev -type f | xargs grep null raven:~ # -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 03/08/2009 07:07 PM, Josef Wolf wrote:
On Sat, Mar 07, 2009 at 07:33:26PM +0100, Anders Johansson wrote:
On Saturday 07 March 2009 19:21:23 Marcus Meissner wrote:
I guess his modification of /etc/bash.bashrc.local and umask 077 is the issue.
KERNEL=="null|zero|full|random|urandom", MODE="0666"
Huh? Where should this line be? I don't seem to have such a line:
raven:~ # find /etc/udev -type f | xargs grep null raven:~ #
It is in /lib/udev/rules.d/50-udev-default.rules -- Joe Morris Registered Linux user 231871 running openSUSE 11.1 x86_64 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Marcus Meissner escribió:
I guess his modification of /etc/bash.bashrc.local and umask 077 is the issue.
Likely, but this IMHO would be still a bug.. -- "If this is the best God can do, I am not impressed" -George Carlin (1937-2008) Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
On Sunday 08 March 2009 15:27:34 Cristian Rodríguez wrote:
Marcus Meissner escribió:
I guess his modification of /etc/bash.bashrc.local and umask 077 is the issue.
Likely, but this IMHO would be still a bug..
That bug would be in whatever it is that deletes /dev/null. The umask is irrelevant. With a default umask, the permissions on /dev/null would be 644, which wouldn't exactly help any /dev/null simply shouldn't be deleted and recreated. That's the bug Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 03/08/2009 12:02 AM, David Haller wrote:
Hello,
On Sat, 07 Mar 2009, Josef Wolf wrote:
On Fri, Mar 06, 2009 at 03:48:55PM +0100, Josef Wolf wrote:
With opensuse-11.1 and kde4, I have seen three times on two different boxes that the mode of /dev/null was changed to 600. This breaks lots of scripts, which assume /dev/null is writable by anybody.
[..]
I think I found the guilty: it is the update of aaa_base. Check out the timestamp:
[..]
2009-03-06 15:03:19 <1> raven(13826) [zypp++] ExternalProgram.cc(start_program):210 Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--force' '--nodeps' '--' '/var/cache/zypp/packages/repo-update/rpm/x86_64/aaa_base-11.1-10007.14.1.x86_64.rpm'
I don't think so. Or if so, it's a x86_64 problem:
# ls -l /dev/null crw-rw-rw- 1 root root 1, 3 Dec 3 06:56 /dev/null # rpm -q --queryformat '%{name}-%{version}-%{release} %{installtime:date}\n' aaa_base aaa_base-11.1-10007.14.1 Wed Mar 4 18:57:41 2009
It isn't a x86_64 problem. joe@jmorris:~> cat /etc/SuSE-release openSUSE 11.1 (x86_64) VERSION = 11.1 joe@jmorris:~> ls -l /dev/null crw-rw-rw- 1 root root 1, 3 2008-12-03 18:29 /dev/null joe@jmorris:~> rpm -q --queryformat '%{name}-%{version}-%{release} %{installtime:date}\n' aaa_base aaa_base-11.1-10007.14.1 Thu 05 Mar 2009 06:17:40 AM PHT -- Joe Morris Registered Linux user 231871 running openSUSE 11.1 x86_64 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, Mar 07, 2009 at 05:02:11PM +0100, David Haller wrote:
Hello,
On Sat, 07 Mar 2009, Josef Wolf wrote:
On Fri, Mar 06, 2009 at 03:48:55PM +0100, Josef Wolf wrote:
With opensuse-11.1 and kde4, I have seen three times on two different boxes that the mode of /dev/null was changed to 600. This breaks lots of scripts, which assume /dev/null is writable by anybody. [..] I think I found the guilty: it is the update of aaa_base. Check out the timestamp: I don't think so. Or if so, it's a x86_64 problem:
No. The same happened on a 32bit machine, also. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2009-03-08 at 11:59 +0100, Josef Wolf wrote:
I think I found the guilty: it is the update of aaa_base. Check out the timestamp: I don't think so. Or if so, it's a x86_64 problem:
No. The same happened on a 32bit machine, also.
Then, assuming it keeps happening, follow Cristian advice, please. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmzv1cACgkQtTMYHG2NR9UHggCfSaBovyCjjpbN/De5e1Atasa1 q8IAoJdqLMcQf0VwRrj5T+84jksFpk83 =d0ao -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Josef Wolf escribió:
No. The same happened on a 32bit machine, also.
Again, we need to know, the exact executable that did this, otherwise we are in a dead end, once you got it, please post rpm --queryformat="%{name}-%{version}-%{release}/%{vendor}\n" -qf <absolute_path_to_executable> So it can get fixed, *possibly* via YOU if the package is part of the official openSUSE distribution, as this is a pretty nasty bug, nothing should ever mess with /dev/null. -- "If this is the best God can do, I am not impressed" -George Carlin (1937-2008) Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
On Sun, Mar 08, 2009 at 10:49:59PM -0300, Cristian Rodríguez wrote:
Josef Wolf escribió:
No. The same happened on a 32bit machine, also.
Again, we need to know, the exact executable that did this, otherwise we are in a dead end, once you got it, please post
Yeah, I've activated the audit, as you posted. But I guess, I have to wait for the next update of aaa_base... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Josef Wolf escribió:
Yeah, Ive activated the audit, as you posted. But I guess, I have to wait for the next update of aaa_base...
zypper install -f aaa_base will also trigger the behsviour then. -- "If this is the best God can do, I am not impressed" -George Carlin (1937-2008) Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
On Mon, Mar 09, 2009 at 05:29:22AM -0300, Cristian Rodríguez wrote:
Josef Wolf escribió:
Yeah, Ive activated the audit, as you posted. But I guess, I have to wait for the next update of aaa_base...
zypper install -f aaa_base will also trigger the behsviour then.
Indeed, it does! But there's no trace of it in the audit. I get an audit entry only for the chmod I use to set it back to 666. I thought this might be because the file gets deleted and recreated instead of chmod'ed. But auditctl -a exit,always -Sunlink -F inode=517712 don't show anything, also. Then I tried (umask 0022 ; zypper install -f aaa_base) and it still gets set to 600, so my umask setting seems not to be the cause. BTW: the inode does _not_ change, so the file is either not deleted at all or the inode is re-used. The latter I'd consider to be too big a coincidence.. What could I try next? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, Mar 09, 2009 at 11:42:16AM +0100, Josef Wolf wrote:
What could I try next?
When I run this command manually: strace rpm --root / --dbpath /var/lib/rpm -U --percent --force --nodeps -- /var/cache/zypp/packages/repo-update/rpm/x86_64/aaa_base-11.1-10007.14.1.x86_64.rpm (that is what zypper runs) the permissions get removed also. But strace don't show anything regarding /dev/null... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, Mar 09, 2009 at 11:55:59AM +0100, Josef Wolf wrote:
On Mon, Mar 09, 2009 at 11:42:16AM +0100, Josef Wolf wrote:
What could I try next?
When I run this command manually:
strace rpm --root / --dbpath /var/lib/rpm -U --percent --force --nodeps -- /var/cache/zypp/packages/repo-update/rpm/x86_64/aaa_base-11.1-10007.14.1.x86_64.rpm
When I add the -f option to strace, I get the following: [ ... ] [pid 16743] access("/usr/sbin/usermod", X_OK) = 0 [ ... ] [pid 16743] wait4(-1, Process 16743 suspended [ ... ] [pid 16872] open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 [pid 16872] close(2) = 0 [pid 16872] dup2(3, 2) = 2 [pid 16872] close(3) = 0 [pid 16872] execve("/usr/sbin/usermod", ["/usr/sbin/usermod", "-g", "nobody", "nobody"], [/* 91 vars */]) = 0 [ ... ] But this don't look very suspicious to me... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, Mar 09, 2009 at 12:08:13PM +0100, Josef Wolf wrote:
On Mon, Mar 09, 2009 at 11:55:59AM +0100, Josef Wolf wrote:
On Mon, Mar 09, 2009 at 11:42:16AM +0100, Josef Wolf wrote:
What could I try next?
When I run this command manually:
strace rpm --root / --dbpath /var/lib/rpm -U --percent --force --nodeps -- /var/cache/zypp/packages/repo-update/rpm/x86_64/aaa_base-11.1-10007.14.1.x86_64.rpm
When I add the -f option to strace, I get the following:
[ ... ] [pid 16743] access("/usr/sbin/usermod", X_OK) = 0 [ ... ] [pid 16743] wait4(-1, Process 16743 suspended [ ... ] [pid 16872] open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 [pid 16872] close(2) = 0 [pid 16872] dup2(3, 2) = 2 [pid 16872] close(3) = 0 [pid 16872] execve("/usr/sbin/usermod", ["/usr/sbin/usermod", "-g", "nobody", "nobody"], [/* 91 vars */]) = 0 [ ... ]
Can you please make the output of 'strace -f' available to us? Thanks, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, Mar 09, 2009 at 12:33:42PM +0100, Michael Schroeder wrote:
Can you please make the output of 'strace -f' available to us?
It is too long (about 2.5mb) to attach it to a mail. Is there any location where I could upload it? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Josef Wolf escribió:
On Mon, Mar 09, 2009 at 12:33:42PM +0100, Michael Schroeder wrote:
Can you please make the output of 'strace -f' available to us?
It is too long (about 2.5mb) to attach it to a mail.
did you compressed it first with lzma ? lzma <file> -- "If this is the best God can do, I am not impressed" -George Carlin (1937-2008) Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
On Mon, Mar 09, 2009 at 12:19:05PM -0300, Cristian Rodríguez wrote:
Josef Wolf escribió:
On Mon, Mar 09, 2009 at 12:33:42PM +0100, Michael Schroeder wrote:
Can you please make the output of 'strace -f' available to us?
It is too long (about 2.5mb) to attach it to a mail.
did you compressed it first with lzma ?
lzma <file>
OK, here it is again compressed.
On Mon, Mar 09, 2009 at 04:24:39PM +0100, Josef Wolf wrote:
On Mon, Mar 09, 2009 at 12:19:05PM -0300, Cristian Rodríguez wrote:
Josef Wolf escribió:
On Mon, Mar 09, 2009 at 12:33:42PM +0100, Michael Schroeder wrote:
Can you please make the output of 'strace -f' available to us?
It is too long (about 2.5mb) to attach it to a mail.
did you compressed it first with lzma ?
lzma <file>
OK, here it is again compressed.
Thanks. The strace indeed reveals what's going on: the aaa_base postinstall scriptlet contains: touch root/.bash_history chmod 600 root/.bash_history On your system, /root/.bash_history is a symlink pointing to /dev/null, thus 'chmod 600 root/.bash_history' changes the mode of /dev/null. The scriptlet should be changed to be a bit more careful, I guess. CC to ro@suse.de, the aaa_base maintainer. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, Mar 09, 2009 at 05:02:03PM +0100, Michael Schroeder wrote:
Thanks. The strace indeed reveals what's going on: the aaa_base postinstall scriptlet contains: touch root/.bash_history chmod 600 root/.bash_history
On your system, /root/.bash_history is a symlink pointing to /dev/null, thus 'chmod 600 root/.bash_history' changes the mode of /dev/null.
Ah, that explains why the attributes were changed. I have set this symlink by intent, BTW. But it does not explain why the audit system have not revealed it.
The scriptlet should be changed to be a bit more careful, I guess. CC to ro@suse.de, the aaa_base maintainer.
Thanks! I hope we agree that symlinking .bash_history to /dev/null should not be forbidden ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-03-09 at 17:37 +0100, Josef Wolf wrote:
But it does not explain why the audit system have not revealed it.
No.... Bugzilla? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm1Y/4ACgkQtTMYHG2NR9WingCglh6byAUemiEYLtfy0X18v9W5 Qi0An3bw9SC/qewHaqZ5a5Y4LbRRXP8S =DSZY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 09 March 2009 11:37:43 am Josef Wolf wrote:
The scriptlet should be changed to be a bit more careful, I guess. CC to ro@suse.de, the aaa_base maintainer.
Thanks! I hope we agree that symlinking .bash_history to /dev/null should not be forbidden ;-)
It is not forbidden to rewire own house. It is just that insurance wouldn't pay when something goes awry. Conclusion: It is better to deal with openSUSE than with insurance companies. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Josef Wolf escribió:
Ah, that explains why the attributes were changed. I have set this symlink by intent, BTW.
Ruediger has fixed this bug in factory, thanks for taking the time to analyze the situation. -- "If this is the best God can do, I am not impressed" -George Carlin (1937-2008) Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
Ruediger has fixed this bug in factory, thanks for taking the time to analyze the situation.
my opensuse 11.1 (x86) system currently offers me Patch: aaa_base Kind: recommended Version: 552 from yast2 online_update at the moment my system is still on aaa_base-11.1-10007.12.1 is this safe to install, or whats the current situation with this bug and package you have been discussing in this thread? will it kill devnull or is this just a special problem with the original reporters setup? thanks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, Mar 10, 2009 at 12:12:21PM +0100, cagsm wrote:
is this safe to install, or whats the current situation with this bug and package you have been discussing in this thread? will it kill devnull or is this just a special problem with the original reporters setup?
As long as you don't have a symbolic link from /root/.bash.history to /dev/null like the original reporter had, the update is safe. Note also that the symbolic link was created on purpose by the reporter, openSUSE does not ship with it. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, Mar 09, 2009 at 09:12:30PM -0300, Cristian Rodríguez wrote:
Josef Wolf escribió:
Ah, that explains why the attributes were changed. I have set this symlink by intent, BTW.
Ruediger has fixed this bug in factory, thanks for taking the time to analyze the situation.
Happened again yesterday: 2009-03-14 12:00:24 <1> raven(14340) [zypp++] ExternalProgram.cc(start_program):210 Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--force' '--nodeps' '--' '/var/tmp/aaa_base-11.1-10007.15.1.x86_64.rpm' Does the fix not work or has it just not made its way into the official update repositories? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, Mar 15, 2009 at 11:11:32AM +0100, Josef Wolf wrote:
On Mon, Mar 09, 2009 at 09:12:30PM -0300, Cristian Rodríguez wrote:
Josef Wolf escribió:
Ah, that explains why the attributes were changed. I have set this symlink by intent, BTW.
Ruediger has fixed this bug in factory, thanks for taking the time to analyze the situation.
Happened again yesterday:
2009-03-14 12:00:24 <1> raven(14340) [zypp++] ExternalProgram.cc(start_program):210 Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--force' '--nodeps' '--' '/var/tmp/aaa_base-11.1-10007.15.1.x86_64.rpm'
Does the fix not work or has it just not made its way into the official update repositories?
No, it was not added to the update repo. (We rereleased the aaa_base,sysvinit update to fix dependency issues.) Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-03-09 at 17:02 +0100, Michael Schroeder wrote:
Thanks. The strace indeed reveals what's going on: the aaa_base postinstall scriptlet contains: touch root/.bash_history chmod 600 root/.bash_history
On your system, /root/.bash_history is a symlink pointing to /dev/null, thus 'chmod 600 root/.bash_history' changes the mode of /dev/null.
Curious. I understood that the mode of a symlink could not be changed, but I did not know that the "target" is changed instead. This is new to me. I suppose it is intentional? :-? cer@nimrodel:/home1/cer/tmp/tmp> touch target cer@nimrodel:/home1/cer/tmp/tmp> ln -s target name cer@nimrodel:/home1/cer/tmp/tmp> l total 0 drwxr-xr-x 2 cer users 30 2009-03-09 19:40 ./ drwxr-xr-x 6 cer users 55 2009-03-09 19:40 ../ lrwxrwxrwx 1 cer users 6 2009-03-09 19:40 name -> target - -rw-r--r-- 1 cer users 0 2009-03-09 19:40 target cer@nimrodel:/home1/cer/tmp/tmp> chmod 600 name cer@nimrodel:/home1/cer/tmp/tmp> l total 0 drwxr-xr-x 2 cer users 30 2009-03-09 19:40 ./ drwxr-xr-x 6 cer users 55 2009-03-09 19:40 ../ lrwxrwxrwx 1 cer users 6 2009-03-09 19:40 name -> target - -rw------- 1 cer users 0 2009-03-09 19:40 target
The scriptlet should be changed to be a bit more careful, I guess. CC to ro@suse.de, the aaa_base maintainer.
There is nothing that can be done to /dev/null to avoid it being changed? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm1Y8YACgkQtTMYHG2NR9WDSwCginO/5FSY1M+Ri9z2m604uTzQ 4GUAn1LdIFUC7UdgfSdKb0D3mFu6V+mP =p6N8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 09 March 2009 13:45:19 Carlos E. R. wrote:
There is nothing that can be done to /dev/null to avoid it being changed?
Not by root. Well, actually, I suppose it could be possible to hack the kernel or file system to reject such as change, but I don't think you really want that. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-03-09 at 12:53 -0600, Boyd Stephen Smith Jr. wrote:
On Monday 09 March 2009 13:45:19 Carlos E. R. wrote:
There is nothing that can be done to /dev/null to avoid it being changed?
Not by root.
:-( I looked at the "sticky" bit, but its purpose is to avoid removal.
Well, actually, I suppose it could be possible to hack the kernel or file system to reject such as change, but I don't think you really want that.
Argh, I suppose not. Mmm, it is actually documented in man chmod! chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used. However, for each symbolic link listed on the command line, chmod changes the permissions of the pointed-to file. In contrast, chmod ignores symbolic links encountered during recursive directory traversals. And the program has no option that I can see to change that behaviour, as far as I can see. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm1alkACgkQtTMYHG2NR9VXdQCfeIj/EvIlOl23qG26zlEzQMI/ prUAnj//2MVVKalrzHzyLD+iWhjIWsPa =IX42 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
the correct permission of /dev/null is rw for user, group, and others ... anything else is wrong and will make you system unusable. This because every program should be able to open /dev/null for read and write. Simply run man 4 null and see. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (12)
-
Anders Johansson -
Boyd Stephen Smith Jr. -
cagsm -
Carlos E. R. -
Cristian Rodríguez -
David Haller -
Dr. Werner Fink -
Joe Morris -
Josef Wolf -
Marcus Meissner -
Michael Schroeder -
Rajko M.