После дополнительных исследований я выяснил, что эти показатели называются overshoot и undershoot.
В GTK 3.16 (например, из ppa:ubuntu-desktop/www), GtkScrolledWindows указывают, есть ли содержимое, которое можно (Adwaita показывает пунктирную линию для этого) и если пользователь прокручивать, когда контента больше нет (Adwaita показывает градиентную штуку). Это называется undershoot и overshoot соответственно.
Ambiance и Radiance не стилизуют эти классы, и по умолчанию показывать непрозрачную серую область. Это выглядит плохо.
Чтобы исправить проблему на fedora с light-gtk3-theme v14.04
я добавил этот CSS в /usr/share/themes/Ambiance/gtk-3.0/gtk-widgets.css:
/*************
* overshoot *
*************/
.overshoot.top {
background: -gtk-gradient(radial, center top, 0, center top, 0.7, from(shade(@bg_color, 0.92)), to(alpha(@bg_color, 0.0)));
}
.overshoot.right {
background: -gtk-gradient(radial, right center, 0, right center, 0.7, from(shade(@bg_color, 0.92)), to(alpha(@bg_color, 0.0)));
}
.overshoot.bottom {
background: -gtk-gradient(radial, center bottom, 0, center bottom, 0.7, from(shade(@bg_color, 0.92)), to(alpha(@bg_color, 0.0)));
}
.overshoot.left {
background: -gtk-gradient(radial, left center, 0, left center, 0.7, from(shade(@bg_color, 0.92)), to(alpha(@bg_color, 0.0)));
}
/**************
* undershoot *
**************/
.undershoot {
background: none;
}
Смотрите revision 436 для Radiance CSS.
Действительно, :вы не можете изменить права доступа к дочернему каталогу, потому что разрешения хранятся для каждого -файла/каталога в -том, что называется -"inode". В этом отношении он безопасен.
Но имя дочернего каталога хранится в родительском каталоге, так как каталог — это специальный файл, содержащий имена файлов (и дочерние каталоги тоже )содержит. А в родительском каталоге у каждого пользователя/группы есть права на запись.
Следовательно, пользователь, которому не принадлежит дочерний каталог, может переименовать его или удалить дочерний каталог, если он пуст. В некоторых системах он может быть даже перемещен в другой каталог, где у него/нее есть права на запись, если он находится в той же файловой системе.
Согласно POSIX, изменение прав доступа к подкаталогу не должно работать:
Only a process whose effective user ID matches the user ID of the file, or a process with appropriate privileges, shall be permitted to change the file mode bits of a file.
Но переименование должно работать, для этого требуется только доступ на запись в содержащую директорию:
(root) /tmp# mkdir -p one/two; chmod 0777 one; chmod 0700 one/two
(user) /tmp/one$ mv two three && echo ok
ok
Хотя, по крайней мере, в Linux, установка липкого бита предотвратит это, так как это предотвратит удаление файлов и каталогов, которыми вы не владеете:
(root) /tmp# chmod +t one
(user) /tmp/one$ mv three four
mv: cannot move 'three' to 'four': Operation not permitted
Я открыто признаю, что понятия не имею о каких-либо особенностях HP -UX, которые могли бы повлиять на это.
Насколько проблематично то, что кто-то может переименовать подкаталог, зависит от того, что вы делаете с этими каталогами. Пользователь, имеющий доступ только к каталогу верхнего уровня -, не может читать никакие файлы в подкаталоге, так что в этом смысле вы в безопасности. Но поскольку они могут переименовывать и воссоздавать каталог с тем же именем, они могут олицетворять все, что там должно быть.
Это имело бы значение, если бы, например. какая-то внешняя служба читает файлы в подкаталоге. Представьте что-то вроде каталога, в котором хранятся файлы crontab
; вы бы не хотели, чтобы кто-то мог создать crontab
на чужое имя.