LINUX.ORG.RU
Ответ на: комментарий от anonymous

Скачал 2.2.26 (вроде последнее стабильное ядро ветки 2.2), нет там 
никакого mem_mmap. Такое ощущение, будто ваш зверек, которым вы "активно пользовались", родился в нестабильной 2.3 и там же умер:

[anonymous@lor src]# grep -C 10 proc_mem_operations linux-2.2.26/fs/proc/mem.c
                        break;
                default:
                        return -EINVAL;
        }
        if (offset < 0)
                        return -EINVAL;
        file->f_pos = offset;
        return offset;
}

static struct file_operations proc_mem_operations = {
        mem_lseek,
        mem_read,
        mem_write,
        NULL,           /* mem_readdir */
        NULL,           /* mem_poll */
        NULL,           /* mem_ioctl */
        NULL,           /* mmap */
        NULL,           /* no special open code */
        NULL,           /* flush */
        NULL,           /* no special release code */
        NULL            /* can't fsync */
};

struct inode_operations proc_mem_inode_operations = {
        &proc_mem_operations,   /* default base directory file-ops */
        NULL,                   /* create */
        NULL,                   /* lookup */
        NULL,                   /* link */
        NULL,                   /* unlink */
        NULL,                   /* symlink */
        NULL,                   /* mkdir */
        NULL,                   /* rmdir */
        NULL,                   /* mknod */
        NULL,                   /* rename */
        NULL,                   /* readlink */

anonymous
()
Ответ на: системные вызовы? через LD_PRELOAD? от Dselect

> Аж ни разу. Можно статически слинковать бинарник. Можно сделать
> бинарник
> SGID'ным. Можно в .interp указать свой interpreter, который не
> обращает внимания на LD_PRELOAD.
>> По тому, что glibc их всех врапит.
> На glibc свет клином не сошелся.
От ё-моё... Цитирую вас же:
---
Работает через LD_PRELOAD, потому системные вызовы не перехватывает,
а только функци из glibc.
---
Не надо вырывать ответ из контекста и ставить для него условия,
прямо противоположные исходным.

> Что такое aoss?
Перехватывает обращения к /dev/dsp и эмулирует его поверх ALSA.

anonymous
()
Ответ на: комментарий от anonymous

> ptrace - чтобы, в частности, сработал read
Для /proc/self/mem - не нужно бы было.

> Думаю, что это была неработающая misfeature
Говорю же вам... пользовались ей от сотворения мира. dosemu, svgalib,
возможно XFree... да мало ли кто ещё? Ничего незаменимого в
этой фишке не было, но и общего способа её заменить вроде бы тоже нет.
dosemu долго страдал без неё, но со временем перешёл на posix shm.
svgalib вообще чуть не сдох и для него в срочном порядке сделали
расширение mremap в виде флага MREMAP_FIXED, чтобы они смогли
переписать утраченную функциональность. Как другие проекты
выкручивались - не в курсе, но все это пережили.

> Скачал 2.2.26 (вроде последнее стабильное ядро ветки 2.2), нет там
> никакого mem_mmap. Такое ощущение, будто ваш зверек, которым вы
> "активно пользовались", родился в нестабильной 2.3 и там же умер:
Да фиг вам. Просто не надо скачивать последнее. Скачайте то, что
было до даты удаления этой фишки. Её удалили сразу во всех ветвях
ядра, а не только в 2.3.

Кстати, не вы ли здесь под ником rtc проходили раньше? Стиль что-то
похожь...

anonymous
()
Ответ на: комментарий от anonymous

>Для /proc/self/mem - не нужно бы было. 

С чего вы взяли, что не нужно? Берем код 2.6.18:

#define MAY_PTRACE(task) \
        (task == current || \
        (task->parent == current && \
        (task->ptrace & PT_PTRACED) && \
         (task->state == TASK_STOPPED || task->state == TASK_TRACED) && \
         security_ptrace(current,task) == 0))


static ssize_t mem_read(struct file * file, char __user * buf,
                        size_t count, loff_t *ppos)
{
        struct task_struct *task = get_proc_task(file->f_dentry->d_inode);
        char *page;
        unsigned long src = *ppos;
        int ret = -ESRCH;
        struct mm_struct *mm;

        if (!task)
                goto out_no_task;

        if (!MAY_PTRACE(task) || !ptrace_may_attach(task))
                goto out;

...


Совершенно очевидно, что при попытке read проверяется, читается ли
 память самого себя или отлаживаемого процесса...

anonymous
()
Ответ на: комментарий от anonymous

> Совершенно очевидно, что при попытке read проверяется, читается ли
> память самого себя или отлаживаемого процесса...
Вопрос на засыпку: /proc/self/mem - это по вашему что? Память самого
себя, или память отлаживаемого процесса?

anonymous
()
Ответ на: комментарий от anonymous

> Вот за такое точно надо руки отрывать...
Почему, кстати? Вроде бы, просто расшаривают PTE. Ну а то, что
оно не работает для SHM и делает do_no_page() всем COW-mappings,
так это не большие проблемы.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.