The crontab solution cannot run properly in the docker container

I believe that many people need to add crontab after looking at the docker container, only to find that it cannot be implemented. And then all sorts of things started to go wrong...

The first, of course, is to look at the log and see that there is no information under /var/log because you did not open rsyslog.

# /etc/init.d/rsyslog start

Keep looking at the log

# tail /var/log/crond
Dec 29 16:39:01 web01-50794 crond[2839]: (root) FAILED to open PAM security session (Cannot make/remove an entry for the specified session)
Dec 29 16:40:01 web01-50794 crond[2842]: (root) FAILED to open PAM security session (Cannot make/remove an entry for the specified session)
Dec 29 16:40:01 web01-50794 crond[2841]: (root) FAILED to open PAM security session (Cannot make/remove an entry for the specified session)
Dec 29 16:41:01 web01-50794 crond[2846]: (root) FAILED to open PAM security session (Cannot make/remove an entry for the specified session)
# tail /var/log/secure
Dec 29 16:39:01 web01-50794 crond[2839]: pam_loginuid(crond:session): set_loginuid failed
Dec 29 16:40:01 web01-50794 crond[2841]: pam_loginuid(crond:session): set_loginuid failed
Dec 29 16:40:01 web01-50794 crond[2842]: pam_loginuid(crond:session): set_loginuid failed
Dec 29 16:41:01 web01-50794 crond[2846]: pam_loginuid(crond:session): set_loginuid failed
# tail /var/log/crond
Dec 29 16:39:01 web01-50794 crond[2839]: (root) FAILED to open PAM security session (Cannot make/remove an entry for the specified session)
Dec 29 16:40:01 web01-50794 crond[2842]: (root) FAILED to open PAM security session (Cannot make/remove an entry for the specified session)
Dec 29 16:40:01 web01-50794 crond[2841]: (root) FAILED to open PAM security session (Cannot make/remove an entry for the specified session)
Dec 29 16:41:01 web01-50794 crond[2846]: (root) FAILED to open PAM security session (Cannot make/remove an entry for the specified session)
# tail /var/log/secure
Dec 29 16:39:01 web01-50794 crond[2839]: pam_loginuid(crond:session): set_loginuid failed
Dec 29 16:40:01 web01-50794 crond[2841]: pam_loginuid(crond:session): set_loginuid failed
Dec 29 16:40:01 web01-50794 crond[2842]: pam_loginuid(crond:session): set_loginuid failed
Dec 29 16:41:01 web01-50794 crond[2846]: pam_loginuid(crond:session): set_loginuid failed

It can be seen from the log of crontab that one session connection cannot be established because of pam.

Then look at the secure log and report set_loginuid failed, unable to get user uid.

Analysis:

Why uid? cannot be obtained in docker; What does ES30en_loginuid. so stand for?

pam_loginuid. so module: session types: used to set the approval process uid. To make the program through the normal review (audit). And in docker, as the kernel ability mechanism of security restrictions, docker started only allow containers are strictly required to use the kernel part of the ability. Including, but not limited to ssh, cron, syslogd, hardware management tool module (such as load module), network configuration, belong to the privileged process. Such as container without access to the privileged process information. The set_loginuid failed that caused the crond service to be started. The required mechanism requires that all validation conditions must be met before the subsequent operation can be carried out, which caused the execution of crond to fail.

There are four values: required, Requisite, sufficient or _optional.

required: indicates that the success of this line and all involved modules is a requirement for user identification. In other words, the program will not be able to pass authentication until all modules with the required tag corresponding to the application are successful. At the same time, if there is an error in any module marked with required, PAM does not immediately return the error message to the application, but does not return the error message to the calling program until all modules have been called. In short, all modules must be executed once, and if any one of the modules fails to validate, the validation will continue and the error message will be returned after the execution is completed. The purpose of this is to protect the system service in a covert way by not letting users know which module they are rejected by. For example, when setting firewall rules, the rules of the reject class are set to drop1, so that users cannot accurately judge whether the network is rejected or the target network is not reachable when accessing the network is unsuccessful.

sufficient: Indicates that the successful validation of this line and the involved modules is sufficient for the user to pass the authentication. This means that as soon as module 1 marked sufficient is verified successfully, PAM immediately returns a successful result to the application without having to try any other modules. Even later cascading modules use the requisite or required control flag. When a module labeled sufficient fails, the sufficient module is treated as optional. So a configuration item with the sufficient flag bit does not cause the entire validation to fail if the validation fails, but the door is open when the validation succeeds. So the use of the control bit must be careful.

Solutions:

# cat /etc/pam.d/crond 
account  required  pam_access.so
account  include  password-auth
#session  required  pam_loginuid.so # Comment on the trip 
session  include  password-auth
auth    include  password-auth
# cat /etc/pam.d/crond 
account  required  pam_access.so
account  include  password-auth
#session  required  pam_loginuid.so # Comment on the trip 
session  include  password-auth
auth    include  password-auth