/dev/null permissions - solved!

Elan Ruusamäe glen at delfi.ee
Thu May 22 23:55:15 CEST 2014


ok, those two subjects aren't only ones to blame, seems "my 
configuration" has caused this.
more particularily, a sqlnet.ora parameter:

LOG_FILE_CLIENT = /dev/null

which i took from 
http://archimedeseureka.blogspot.com/2011/08/disabling-logging-for-oracle-instant.html

On 23.05.2014 00:42, Elan Ruusamäe wrote:
> 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



More information about the pld-devel-en mailing list