Problem with SGID and new inode

2012-11-22 Thread Giorgos Kappes
Ηι,

I was looking at the source code of the ceph MDS and in particular at
the function
CInode* Server::prepare_new_inode(...) in the mds/Server.cc file which
creates a new inode.
At lines 1739-1747 the code checks if the parent directory has the
set-group-ID bit set. If
this bit is set and the new inode refers to a directory then the new
inode should also have
the set-group-ID bit set. However, as I understand, at line 1744 the
set-group-ID bit is set
at the local variable [mode |= S_ISGID] and not on the inode.
Shouldn't this line be
[in-inode.mode |= S_ISGID;]?

To illustrate the above problem I tried to create a new directory
inside a directory that has
the set-group-ID bit set:

root@client-admin:/mnt/admin# mkdir mydir
root@client-admin:/mnt/admin# chmod +s mydir
root@client-admin:/mnt/admin# ls -l
total 1
drwsr-sr-x 1 root root  0 Nov 22  2012 mydir
-rw-r--r-- 1 root root 13 Oct 19 08:05 myfile.txt
root@client-admin:/mnt/admin# cd mydir
root@client-admin:/mnt/admin/mydir# mkdir newdir
root@client-admin:/mnt/admin/mydir# ls -l
total 1
drwxr-xr-x 1 root root 0 Nov 22  2012 newdir

Finally, I would like to note that I am using Ceph 0.48.2 but the
above problem also seems
to exist in the v0.54 development release.

Best regards,
Girogos Kappes

---
Giorgos Kappes
Website: http://www.cs.uoi.gr/~gkappes
email: geok...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Ceph kernel client - kernel craches

2012-05-10 Thread Giorgos Kappes
+0xb2/0xb7
[75146.035616]  [815a2a47] ? ceph_msg_kfree+0x3e/0x47
[75146.035616]  [8100ef69] ? do_invalid_op+0x8b/0x95
[75146.035616]  [810f55df] ? kfree+0x59/0xc2
[75146.035616]  [81515b94] ? inet_recvmsg+0x64/0x75
[75146.035616]  [815a2a50] ? ceph_msg_kfree+0x47/0x47
[75146.035616]  [815d389b] ? invalid_op+0x1b/0x20
[75146.035616]  [815a2a47] ? ceph_msg_kfree+0x3e/0x47
[75146.035616]  [815a2a50] ? ceph_msg_kfree+0x47/0x47
[75146.035616]  [814f9620] ? tcp_recvmsg+0x773/0x95e
[75146.035616]  [810f55df] ? kfree+0x59/0xc2
[75146.035616]  [815a2a50] ? ceph_msg_kfree+0x47/0x47
[75146.035616]  [815a2a47] ? ceph_msg_kfree+0x3e/0x47
[75146.035616]  [81372b8e] ? kref_put+0x34/0x3e
[75146.035616]  [8137513d] ? ceph_mdsc_release_request+0x2f/0x145
[75146.035616]  [8137510e] ? encode_caps_cb+0x2f9/0x2f9
[75146.035616]  [81372b8e] ? kref_put+0x34/0x3e
[75146.035616]  [813778d3] ? dispatch+0xe05/0x132c
[75146.035616]  [814b3d5e] ? kernel_recvmsg+0x34/0x3f
[75146.035616]  [813dce42] ? crc32c+0x56/0x7c
[75146.035616]  [815a39c7] ? ceph_tcp_recvmsg+0x43/0x4f
[75146.035616]  [815a658b] ? con_work+0x15ac/0x17a8
[75146.035616]  [8104483f] ? lock_timer_base+0x25/0x49
[75146.035616]  [815a4fdf] ? ceph_fault+0x2b4/0x2b4
[75146.035616]  [8104ef8a] ? process_one_work+0x1cd/0x2eb
[75146.035616]  [8104f1d6] ? worker_thread+0x12e/0x249
[75146.035616]  [8104f0a8] ? process_one_work+0x2eb/0x2eb
[75146.035616]  [8104f0a8] ? process_one_work+0x2eb/0x2eb
[75146.035616]  [81052b82] ? kthread+0x81/0x89
[75146.035616]  [815d3a24] ? kernel_thread_helper+0x4/0x10
[75146.035616]  [81052b01] ? kthread_freezable_should_stop+0x53/0x53
[75146.035616]  [815d3a20] ? gs_change+0x13/0x13
[75146.035616] Code: 41 5e 41 5f c3 41 bf ea ff ff ff eb 97 90 90 90
65 48 8b 04 25 c0 c6 00 00 48 8b 80 a0 02 00 00 8b 40 f0 c3 48 8b 87
a0 02 00 00 48 8b 40 f8 c3 48 3b 3d 51 5f 95 00 75 08 0f bf 87 6a 06
00 00
[75146.035616] RIP  [81052783] kthread_data+0x7/0xc
[75146.035616]  RSP 8800bbb35900
[75146.035616] CR2: fff8
[75146.035616] ---[ end trace 18e2f523c5af9a3b ]---
[75146.035616] Fixing recursive fault but reboot is needed!
[75206.036002] INFO: rcu_sched detected stalls on CPUs/tasks: { 1}
(detected by 3, t=15002 jiffies)
[75206.036265] Pid: 0, comm: swapper/3 Tainted: G      D      3.3.4 #1
[75206.036371] Call Trace:
[75206.036464]  IRQ  [8109b7b3] ? __rcu_pending+0x21a/0x336
[75206.036635]  [81075d59] ? tick_nohz_handler+0xcb/0xcb
[75206.036740]  [8109b9cc] ? rcu_check_callbacks+0xa7/0xe7
[75206.036846]  [81075d59] ? tick_nohz_handler+0xcb/0xcb
[75206.036951]  [81044911] ? update_process_times+0x31/0x63



Thanks a lot,
Giorgos Kappes

On Tue, May 8, 2012 at 10:18 PM, Tommi Virtanen t...@inktank.com wrote:
 On Tue, May 8, 2012 at 8:43 AM, Giorgos Kappes geok...@gmail.com wrote:
 When I am running deboostrap to install a base Debian Squeeze system
 on a Ceph directory the client's kernel crashes with the following
 message:

 I: Extracting zlib1g...
 W: Failure trying to run: chroot /mnt/debian mount -t proc proc /proc
 [  759.776151] kernel tried to execute NX-protected page - exploit
 attempt? (uid: 0)
 [  759.776169] BUG: unable to handle kernel paging request at 
 e8fe4ab0
 ...
 [  759.776438]  [81099405] ? __rcu_process_callbacks+0x1c7/0x2f8
 [  759.776447]  [81099898] ? rcu_process_callbacks+0x2c/0x56
 [  759.776457]  [8104cb72] ? __do_softirq+0xc4/0x1a0
 [  759.776465]  [81096875] ? handle_percpu_irq+0x3d/0x54
 [  759.776475]  [8150efb6] ? __xen_evtchn_do_upcall+0x1c7/0x205
 [  759.776484]  [8176e52c] ? call_softirq+0x1c/0x30
 [  759.776493]  [8100fa47] ? do_softirq+0x3f/0x79
 [  759.776501]  [8104c942] ? irq_exit+0x44/0xb5
 [  759.776508]  [8150ffc6] ? xen_evtchn_do_upcall+0x27/0x32
 [  759.776516]  [8176e57e] ? xen_do_hypervisor_callback+0x1e/0x30
 ...
 My simple cluster consists of 3 nodes in total. Each node is a Xen
 domU guest running the Linux kernel 3.2.6 and ceph 0.43. For
 reference, here is my configuration:
 ...
 My Ceph kernel client is another Xen domU node running the Linux
 kernel 3.2.11. I have also tried a native client with the same result.
 Please note that this bug happens only in the client side.
 Your help would be greatly appreciated.

 Your backtrace includes Xen code in it -- can you reproduce this bug
 with a mainline kernel, without Xen at all?

 Also, the error encountered is from the NX security subsystem. It
 would be nice to know what would happen without NX.



---
Giorgos Kappes
Website: http://www.cs.uoi.gr/~gkappes
email

Ceph kernel client - kernel craches

2012-05-08 Thread Giorgos Kappes
]  [81099405] ? __rcu_process_callbacks+0x1c7/0x2f8
[  759.776853]  [81099898] ? rcu_process_callbacks+0x2c/0x56
[  759.776861]  [8104cb72] ? __do_softirq+0xc4/0x1a0
[  759.776868]  [81096875] ? handle_percpu_irq+0x3d/0x54
[  759.776876]  [8150efb6] ? __xen_evtchn_do_upcall+0x1c7/0x205
[  759.776883]  [8176e52c] ? call_softirq+0x1c/0x30
[  759.776891]  [8100fa47] ? do_softirq+0x3f/0x79
[  759.776898]  [8104c942] ? irq_exit+0x44/0xb5
[  759.776905]  [8150ffc6] ? xen_evtchn_do_upcall+0x27/0x32
[  759.776913]  [8176e57e] ? xen_do_hypervisor_callback+0x1e/0x30
[  759.776919]  EOI  [81006f3f] ?
xen_restore_fl_direct_reloc+0x4/0x4
[  759.776931]  [810013aa] ? hypercall_page+0x3aa/0x1000
[  759.780132]  [810013aa] ? hypercall_page+0x3aa/0x1000
[  759.780132]  [8163969b] ? cpuidle_idle_call+0x16/0x1af
[  759.780132]  [810068dc] ? xen_safe_halt+0xc/0x15
[  759.780132]  [810150a6] ? default_idle+0x4b/0x84
[  759.780132]  [8100ddf6] ? cpu_idle+0xb9/0xef
[  759.780132]  [81cf7bff] ? start_kernel+0x395/0x3a0



My simple cluster consists of 3 nodes in total. Each node is a Xen
domU guest running the Linux kernel 3.2.6 and ceph 0.43. For
reference, here is my configuration:

; 
---
;
; ceph ceph.conf file.
;
; This file defines cluster membership, the various locations
; that Ceph stores data, and any other runtime options.

[global]
; enable secure authentication
auth supported = cephx

; keyring placement
keyring = /etc/ceph/$name.keyring
; allow ourselves to open a lot of files
; max open files = 131072

; set log file
; log file = /var/log/ceph/$name.log
; log_to_syslog = true; uncomment this line to log to syslog

; set up pid files
; pid file = /var/run/ceph/$name.pid

; If you want to run a IPv6 cluster, set this to true.
Dual-stack isn't possible
; ms bind ipv6 = true

; monitors
[mon]
mon data = /mnt/store/$name

[mon.a]
host = sm-ceph0
mon addr = 192.168.2.254:6789

[mds]
; where the mds keeps it's secret encryption keys
;keyring = /data/keyring.$name

[mds.a]
host = sm-ceph0

[osd]
; This is where the btrfs volume will be mounted.
osd data = /mnt/store/$name

; This is a file-based journal.
osd journal = /mnt/store/$name/$name.journal
osd journal size = 1000 ; journal size, in megabytes

; You can change the number of recovery operations to speed up recovery
; or slow it down if your machines can't handle it
; osd recovery max active = 3

[osd.0]
host = sm-ceph0
btrfs devs = /dev/xvda3

; If you want to specify some other mount options, you can do so.
; The default values are rw,noatime
; btrfs options = rw,noatime

[osd.1]
host = sm-ceph1
btrfs devs = /dev/xvda3

[osd.2]
host = sm-ceph2
btrfs devs = /dev/xvda3
; 
---
My Ceph kernel client is another Xen domU node running the Linux
kernel 3.2.11. I have also tried a native client with the same result.
Please note that this bug happens only in the client side.
Your help would be greatly appreciated.

Thanks,
Giorgos Kappes


---
Giorgos Kappes
Website: http://www.cs.uoi.gr/~gkappes
email: geok...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html