Это не то, как вы подходите к проблеме. Как только вы предоставляете доступ к оболочке пользователю, вы поручаете этому пользователю делать все, на что у него есть соответствующие разрешения. Забудьте о регистрации команд, есть слишком много способов выполнить команду в любой системе Unix.
Например, пользователь может запустить почтовый клиент (например, единственная зарегистрированная команда pine
), там он выбирает «Compose», который запускает VI, и из VI он запускает любую команду, через которую хочет :!cmd
. Эта команда нигде не регистрируется, и с точки зрения системы она похожа на любое вспомогательное приложение, вызываемое VI, например, grep или sort. Единственная команда, зарегистрированная оболочкой, была pine
.
Кажется, что вы на самом деле хотите, называется одитингом . Включите подсистему аудита и используйте auditctl
команду и auditd
демон из пакета аудита для управления тем, что регистрируется. Более подробная информация находится на странице руководства audctl (8) .
Обратите внимание, что регистрация каждого экземпляра процесса также может быть неоптимальной. Например, простой ./configure
для пакета программного обеспечения (созданный с помощью автоинструментов) отличается тем, что создает тысячи экземпляров процессов. Это наполнит журнал аудита таким большим шумом, что потом будет очень трудно его анализировать.
Похоже, вы ищете что-то вроде rooth ( man page ). Чтобы процитировать man страницу:
Несмотря на название, это может быть использовано для любого пользователя.
источник
Вероятно, лучше, если пользователи будут использовать sudo (или аналогичные) для запуска команд, которые вам интересны, и доверять пользователям на каком-то уровне. По мере того, как вы приближаетесь к «полному контролю» вещей, становится сложнее отследить, что они делают. Например, недавно я смотрел на такие инструменты. В основном они просто создают журналы, которыми трудно управлять, если у вас достаточно пользователей и компьютеров, чтобы сделать такую вещь стоящей. :)
Учитывайте всю информацию, которую вы будете генерировать. Насколько это тебя волнует? Вероятно, очень мало - поэтому вы создаете журналы, которые в основном бесполезны. Аудит того, что вам действительно небезразлично, как предлагают другие, вероятно, приведет вас к лучшему конечному состоянию.
источник
Bash может быть скомпилирован с поддержкой syslog начиная с 4.1.
Это не надежно (учет процессов может быть лучше для этого), но это в основном взаимодействие с пользователем; объем должен быть более управляемым, и вы сможете переключиться на что-то более подробное, если подозреваете что-то ненормальное.
Тем не менее, это очень навязчиво, и как пользователь я бы ожидал очень конкретного предупреждения о конфиденциальности, прежде чем вы начнете это делать.
источник
Также есть sudosh ( http://sudosh.sourceforge.net ), который будет вести логи сеанса. У вас есть возможность запустить его как определенную оболочку для пользователя или через sudo. Он также отслеживает время для каждого сеанса, так что вы можете воспроизвести сеанс и просмотреть его (включая редактирование сеансов и еще много чего).
источник