/proc/ leesbaar maken, hoe?

[Lennardnl]

Hi!

Ik ben een Minecraft-server aan het opzetten, met een Multicraft controlepanel erbij. Nu draait dat allemaal als een zonnetje, op één ding na: hij kan de prestaties van de CPU en geheugen niet bijhouden, en dat komt omdat de mappen in /proc/{procesid}/ niet leesbaar zijn, die zijn namelijk alleen leesbaar en uitvoerbaar door de eigenaar (0500).
Op een andere server heb ik het wél werkend, en daar zijn de mappen voor eigenaar, groep en anderen allemaal leesbaar en uitvoerbaar (0555).

Hoe krijg ik het nu zo dat die procesmappen op deze andere server ook 0555 krijgen ipv 0500?
Ik zit al een paar uur te zoeken op internet, maar kan er helaas weinig over vinden...

Ik draai overigens Ubuntu 12.10.

Alvast bedankt!
Lennard

[acemoo]

code:

chmod 504 /proc

zou moeten werken, weet alleen niet of dat (beveiligings) problemen gaat geven dat je alles lees rechten geeft op /proc.

[Lennardnl]

Maar de map zelf heeft al wel op beide servers 0555 als rechten (dat is voor eigenaar, groep en anderen lezen + schrijven), dus dan zou dat toch al goed moeten zijn?
Alleen de nieuwe proces-mappen erin erven die 0555 niet over ofzo.

[ Voor 17% gewijzigd door Lennardnl op 12-01-2013 22:43 ]

[acemoo]

/proc/{procesid}/ moet natuurlijk ook minimaal 004 zijn zodat je paneel er bij kan.
Wie is de eigenaar van het proces? misschien kan je je controle paneel ook op die gebruiker draaien.

[Lennardnl]

br men schreef op zaterdag 12 januari 2013 @ 22:49:
/proc/{procesid}/ moet natuurlijk ook minimaal 004 zijn zodat je paneel er bij kan.
Wie is de eigenaar van het proces? misschien kan je je controle paneel ook op die gebruiker draaien.

Het zit zo: het panel zelf is 'minecraft', maar de servertjes zelf zijn 'mc1' en 'mc2' en 'mc3', enzovoorts.. elke minecraft-server draait onder een eigen gebruiker, dus dat gaat niet zo makkelijk volgens mij.

Maar ik vind het al vreemd dat /proc/ op beide servers 0555 is, maar dat op de 'goede' server de nieuwe /proc/{proces_id}/ mappen ook 0555 worden, maar dat ze op de 'foute' server 0500 worden, dat moet toch door een of andere instelling komen lijkt me?

[acemoo]

lijkt er wel op ja

[Hero of Time]

Check even het volgende:
- Mount opties voor /proc;
- Eigenaar van de PID map;
- Werkelijke gebruiker die 't proces heeft gestart. Is het root die naar user verandert, of direct de betreffende user?

Let ook op dat mappen altijd execute rechten moet hebben. Mist 't, dan kan je er niet in. Mode 5 is read/execute, 6 is read/write.

De gebruiker die het process heeft gestart kan ten alle tijden in de map lezen. Let dus ook op onder welke gebruiker je panel draait, en welke groepen deze lid van is. Vergelijk zo veel mogelijk van je configuratie met de server die wel werkt.

[Lennardnl]

Ai, zo handig ben ik er ook weer niet in, maar ik ga m'n best doen je tips te verwerken.

Wat opvalt is dat ALLE mappen in /proc/ op de 'goede' server r-xr-xr-x (0555) hebben, en ALLE mappen in /proc/ op de 'foute' server r-x------ (0500) hebben (van ALLE processen dus), het heeft dus m.i. niets te maken met de user die het proces opstart.

Als ik "cat /etc/fstab" doe, krijg ik op de goede server dit:

code:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=c8349a54-2bc3-4aac-xxxxxxxxxxx /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=40f413ba-e716-4722-xxxxxxxxxxxxxx none            swap    sw              0       0

en op de foute server dit:

code:

/dev/md1    /   ext4    errors=remount-ro,relatime  0   1
/dev/md2    /home   ext4    defaults,relatime   0   2
/dev/sda3   none    swap    defaults    0   0
/dev/sdb3   none    swap    defaults    0   0
----proc        /proc   proc    defaults        0   0
sysfs       /sys    sysfs   defaults        0   0
dev     /dev    devtmpfs    rw  0   0

(ik heb een deel van de UUID's weggehaald, weet niet of dat kwaad kan)
dus dat is al vreemd, op de foute server is er heel veel gemount en op die andere in fstab bijna niets?

bij mtab is dit de goede server:

code:

/dev/sda1 / ext4 rw,errors=remount-ro 0 0
----proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
none /sys/fs/fuse/connections fusectl rw 0 0
none /sys/kernel/debug debugfs rw 0 0
none /sys/kernel/security securityfs rw 0 0
udev /dev devtmpfs rw,mode=0755 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=0620 0 0
tmpfs /run tmpfs rw,noexec,nosuid,size=10%,mode=0755 0 0
none /run/lock tmpfs rw,noexec,nosuid,nodev,size=5242880 0 0
none /run/shm tmpfs rw,nosuid,nodev 0 0
none /run/user tmpfs rw,noexec,nosuid,nodev,size=104857600,mode=0755 0 0

en dit de foute:

code:

rootfs / rootfs rw 0 0
/dev/root / ext4 rw,relatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,mode=600 0 0
----none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
----none /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /run tmpfs rw,nosuid,noexec,relatime,size=807020k,mode=755 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
none /run/user tmpfs rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755 0 0
/dev/md2 /home ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0

(ik heb zelf even ---- voor de proc mappen gezet zodat die voor jullie sneller te zien zijn)

Wat opvalt is dat er bij de foute configuratie 'none' voor /proc staat, maar ik heb geen flauw idee wat dat inhoudt.
Verder is die mount-regel het zelfde, op de 'relatime' na, maar dat heeft hier niets mee te maken lijkt me.

Waar het verder nog qua configuratie eventueel kan verschillen weet ik niet, ik heb al van alles geprobeerd met umask maar ik kom er niet verder mee...

Thanks voor de reacties trouwens.

[FRidh]

Wat opvalt is dat er bij de foute configuratie 'none' voor /proc staat, maar ik heb geen flauw idee wat dat inhoudt.
Verder is die mount-regel het zelfde, op de 'relatime' na, maar dat heeft hier niets mee te maken lijkt me.

None houdt in dat de mount geen hardware device gebruikt. relatime heeft te maken met een bepaalde eigenschap die elk bestand heeft. Beide hebben inderdaad niets met dit probleem te maken.

Staat er wellicht iets als

code:

chmod 500 /proc/

in de ~/.profile van de gebruikers op de 'foute' server?

[H!GHGuY]

http://lwn.net/Articles/131557/

Doe eens

code:

cat /proc/cmdline

op beide servers?

[Lennardnl]

FRidh schreef op zondag 13 januari 2013 @ 00:37:
Staat er wellicht iets als

code:

chmod 500 /proc/

in de ~/.profile van de gebruikers op de 'foute' server?

Nope, dat staat niet in /root/.profile als je die bedoelt, daar staat helemaal niets in met chmod oid.

H!GHGuY schreef op zondag 13 januari 2013 @ 08:38:

Doe eens

code:

cat /proc/cmdline

op beide servers?

foute server:
BOOT_IMAGE=/boot/bzImage-3.2.13-xxxx-grs-ipv6-64 root=/dev/md1 ro

goede server:
BOOT_IMAGE=/boot/vmlinuz-3.5.0-17-generic root=UUID=c8349a54-2bc3-4aac-b623-xxxxxxxxxxxx ro
(xxx'en heb ik weggeknipt)

Het is een dedi van OVH dus misschien dat die een gaar beveiligingsprogramma standaard in de installatie hebben gestopt ofzo.

Die link van jou is ook bedoeld om onderscheid te maken tussen verschillende gebruikers enzo, maar dat heb ik allemaal niet nodig volgens mij: ik wil alleen dat nieuwe /proc/{proces_id}/ mappen rechten 0555 krijgen, verder zijn de groepen en alles helemaal goed...

Overigens doet het programma grsecurity o.a. dit volgens Wikipedia:
"List of additional features and security improvements:
/proc restrictions that don't leak information about process owners"

dus misschien dat dat geinstalleerd is, nu nog even uitzoeken hoe ik dat weet.
edit; Nope, niet geïnstalleerd. ACL is wel op de goede server geïnstalleerd en niet op de foute.

Ook zie ik nu (edit) dat op de 'foute' server er 7 mappen in /proc/{proces_id}/ staan, en op de goede server 9. De mappen die op de goede server er nog bij staan, zijn: /proc/attr/ en /proc/map_files/, dus ik zoek daar nog maar weer verder mee. Oh, dat moet niet uitmaken, want op een andere server die het ook goed doet staan er ook maar 7 mappen in, die server heeft wel ook /proc/attr/, maar geen /proc/map_files/ en ook geen /proc/ns/.

Mocht iemand zin en tijd hebben dan kan ik eventueel toegang tot de server geven, het is verder een kale installatie.

[ Voor 49% gewijzigd door Lennardnl op 13-01-2013 12:20 ]

[Hero of Time]

Op mijn Debian Sid heb ik dit in fstab mbt /proc:

code:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0

Welke distro's worden er gebruikt op je servers? De 'goede' lijkt op Ubuntu, maar de 'foute' draait wat anders, gezien de kernel. Als je het niet weet, kan je met 'lsb_release -a' het antwoord krijgen:

code:

Distributor ID: Debian
Description:    Debian GNU/Linux 7.0 (wheezy)
Release:    7.0
Codename:   wheezy

ACL is wel iets waar je naar kan kijken. Omdat het op de goede wel staat, maar de foute niet, is er misschien een configuratie in gezet dat 555 geeft.

Ik heb geen ideeën meer.

[jimmy87]

Je foute server heeft een kernel met grsec, wat dus wil zeggen dat die extra beveiligingsopties heeft voor je server. Dat is de standaard kernel bij OVH, daarom kan het ook best dat je cpu en mem niet uit te lezen zijn.

[Lennardnl]

jimmy87 schreef op zondag 13 januari 2013 @ 13:28:
Je foute server heeft een kernel met grsec, wat dus wil zeggen dat die extra beveiligingsopties heeft voor je server. Dat is de standaard kernel bij OVH, daarom kan het ook best dat je cpu en mem niet uit te lezen zijn.

Genius

Ik heb dit gedaan (ook even een reminder voor mezelf als ik weer een keer een OVH server heb):
apt-get install linux-image-server
mv /etc/grub.d/06_OVHkernel /etc/grub.d/25_OVHkernel
update-grub
shutdown -r now
[ zie ook http://www.sysadminworld....ard-ubuntu-kernel-on-ovh/ ]

en het werkt

Echt bedankt allemaal!!

_{ben gewoon sinds gistermiddag al bezig om dit te fixen}