/dev/null permissions - "solved"

[Elan Ruusamäe]

FUCK YOU ORACLE & PHP!

each time i run php with pdo-oci installed (compiled with 
oracle-instantclient 12.1.0.1.0) while having umask 007, /dev/null gets 
fucked up to 0660 permission.

... it's like punishment for running php as root!

root at rotten-fruit# chmod 777 /dev/null; ls -l /dev/null; umask 7; php -n 
-m; ls -l /dev/null
crwxrwxrwx 1 root root 1, 3 mai   13 12:28 /dev/null
[PHP Modules]
Core
date
ereg
libxml
Reflection
standard

[Zend Modules]

crwxrwxrwx 1 root root 1, 3 mai   13 12:28 /dev/null


root at rotten-fruit# chmod 777 /dev/null; ls -l /dev/null; umask 7; php -n 
-dextension=spl.so -dextension=pdo.so -dextension=pdo_oci.so -m; ls -l 
/dev/null

crwxrwxrwx 1 root root 1, 3 mai   13 12:28 /dev/null

[PHP Modules]
Core
date
ereg
libxml
PDO
PDO_OCI
Reflection
SPL
standard

[Zend Modules]

crwxrwx--- 1 root root 1, 3 mai   13 12:28 /dev/null



On 22.05.2014 13:20, Elan Ruusamäe wrote:
> this has "escalated" to one of my vservers.
> which is weird as i thought vservers can't alter permissions of device 
> nodes.
>
> crw-rw---- 1 root root 1, 3 Jul  8  2008 /dev/null
>
> i'm suspecting bash being the cause of the poison, as it was recently 
> updated there
>
> # rpm -q bash --blink
> bash-4.3.11-1.i686.rpm
>         <= bash-4.3.0-1.i686.rpm
>
>
> On 19.05.2014 21:39, Elan Ruusamäe wrote:
>> something funny is happening on one of my machine
>>
>> /dev/null permissions get reset to 660 (which is common for root 
>> umask 7 i'm using)
>> i have not found pattern in how or when it gets changed
>> i have stopped crond and still /dev/null premissions get reset to 660 
>> opposed to sane 666 permission
>>
>> i've added auditd rule to track this, but unfortunately it's not 
>> giving any useful information how the permissions get reset to 660
>>
>> my /etc/audit/audit.rules:
>> -D
>> -b 320
>> -w /dev/null -p a
>>
>>
>> any ideas:
>> 1) wtf causes this?
>> 2) how to try to audit system to figure it out?
>>
>> i'm thinking something running as root is "fixing" it's own 
>> permissions via fchmod which is "accidentally" linked to /dev/fd/2 => 
>> /dev/null
>> i've tried to mv /dev/null /dev/null1; mknod /dev/null, but that did 
>> not stop the activities in that system
>>
>>
>
>


-- 
glen