Tutti i comandi nel mio crontab falliscono con "Autorizzazione negata"


10

Aggiornamento: a questo problema non verrà data una risposta definitiva; Mi sono trasferito in un'altra distribuzione e da allora non ho più riscontrato questo problema. Non sono mai stato in grado di risolverlo con le risposte perspicaci disponibili al momento, ma l'efficienza del carburante può variare (YMMV).


crontab -ee crontab -lfunziona bene:

$ crontab -l | grep -v '^#'
* * * * * /usr/bin/env
* * * * * echo 'Hello from crontab'

Tuttavia, vedo due messaggi come questo ogni minuto in /var/log/syslog:

Mon DD hh:mm:01 username CRON[PID]: Permission denied

Quindi il crontab viene letto , ma in qualche modo non è in grado di eseguire nulla (ovviamente ho verificato i comandi quando ho effettuato l'accesso come lo stesso utente). Qualche idea sul perché?

/etc/cron.allowe /etc/cron.denynon esistono.

crontab è impostato setuid gruppo:

$ stat --format '%A %U %G' /usr/bin/crontab
-rwxr-sr-x root crontab

La directory crontabs sembra avere le autorizzazioni giuste:

$ stat --format '%A %U %G' /var/spool/cron/crontabs
drwx-wx--T root crontab

Il crontab stesso è di mia proprietà (non a caso, dato che sono in grado di modificarlo):

$ sudo stat --format '%A %U %G' /var/spool/cron/crontabs/$USER
-rw------- username crontab

Sono non un membro del crontabgruppo.

Queste righe appaiono in /var/log/auth.logogni minuto (grazie @Alaa):

Mon DD hh:mm:01 username CRON[1752]: pam_unix(cron:session): session opened for user username by (uid=0)
Mon DD hh:mm:01 username CRON[1752]: PAM bad jump in stack

Forse PAM è rotto? pam-auth-update(grazie @coteyr) elenca tutti questi e tutti sono abilitati:

  • Autenticazione Unix
  • Demone portachiavi GNOME - Gestione portachiavi di accesso
  • eCryptfs Key / Mount Management
  • ConsoleKit Session Management
  • Gestione ereditaria delle capacità

Qualcuno può essere disabilitato in modo sicuro? Non sto usando alcun filesystem crittografato.

Sulla base di una voce di bug Debian ho provato a eseguire debconf-show libpam-runtimee ho ricevuto il seguente messaggio di errore:

debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission denied

I contenuti di /etc/pam.d/cron:

# The PAM configuration file for the cron daemon

@include common-auth

# Read environment variables from pam_env's default files, /etc/environment
# and /etc/security/pam_env.conf.
session       required   pam_env.so

# In addition, read system locale information
session       required   pam_env.so envfile=/etc/default/locale

@include common-account
@include common-session-noninteractive 

# Sets up user limits, please define limits for cron tasks
# through /etc/security/limits.conf
session    required   pam_limits.so

session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid

I file menzionati ( /etc/environment, pam_env.so, /etc/default/locale, pam_limits.so, pam_succeed_if.so) sono tutti leggibili da mio utente.

Su un altro host con Ubuntu 13.04, con lo stesso utente crontab, no /etc/cron.{allow,deny}, stesse autorizzazioni di cui sopra e non essendo un membro del crontabgruppo, funziona perfettamente (registra i comandi ma non l'output /var/log/syslog).


Modificando la prima riga crontab:

* * * * * /usr/bin/env >/tmp/env.log 2>&1

e verificando che / tmp sia scrivibile in tutto il mondo:

$ sudo -u nobody touch /tmp/test
$ ls /tmp/test
/tmp/test
$ ls -ld /tmp
drwxrwxrwt 15 root root 12288 May 27 10:18 /tmp

Ho verificato che i comandi crontab non vengono eseguiti affatto : i Permission deniedmessaggi vengono comunque visualizzati in /var/log/syslog, ma /tmp/env.lognon sono stati creati.


Sulla base di un elenco casuale di /etc/pam.dimpostazioni ho riscontrato le seguenti discrepanze:

$ grep '^[^#]' /etc/pam.d/sshd 
@include common-auth
account    required     pam_nologin.so
@include common-account
@include common-session
session    optional     pam_motd.so # [1]
session    optional     pam_mail.so standard noenv # [1]
session    required     pam_limits.so
session    required     pam_env.so # [1]
session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale
@include common-password
$ grep '^[^#]' /etc/pam.d/common-session
session [default=1]         pam_permit.so
session requisite           pam_deny.so
session required            pam_permit.so
session optional            pam_umask.so
session required    pam_unix.so 
session optional    pam_ecryptfs.so unwrap
session optional            pam_ck_connector.so nox11
$ grep '^[^#]' /etc/pam.d/common-account
account [success=1 new_authtok_reqd=done default=ignore]    pam_unix.so 
account requisite           pam_deny.so
account required            pam_permit.so
$ grep '^[^#]' /etc/pam.d/common-session-noninteractive 
session [default=1]         pam_permit.so
session requisite           pam_deny.so
session required            pam_permit.so
session optional            pam_umask.so
session required    pam_unix.so 
session optional    pam_ecryptfs.so unwrap

Pacchetti PAM installati:

$ dpkg --get-selections | grep --invert-match deinstall | cut --fields 1 | grep pam
libpam-cap
libpam-ck-connector
libpam-gnome-keyring
libpam-modules
libpam-modules-bin
libpam-runtime
libpam0g
python-pam

Ho provato a reinstallare questi - non ha aiutato:

$ sudo apt-get install --reinstall $(dpkg --get-selections | grep --invert-match deinstall | cut --fields 1 | grep pam)

Non riesco a eliminare e quindi reinstallare questi a causa di dipendenze non soddisfatte.


Hai provato ad accedere come cron ed eseguire i comandi?
NotFromBrooklyn,

@ l0b0, che dire delle autorizzazioni del file crontab stesso, all'interno della cartella crontabs, ovvero /var/spool/cron/crontabs/username?
Alaa Ali,

1
Hmm. Cosa /var/log/auth.logdice CRON?
Alaa Ali,

@NotFromBrooklyn id cron->id: cron: No such user
l0b0

1
@ssoto Come faccio a scoprirlo? Io sono un locale di utente, se è questo che vuoi dire.
l0b0,

Risposte:


2

PAM bad jump in stack è un grande indizio.

Il tuo /etc/pam.d/crondifferisce dalla versione di serie con l'aggiunta di una riga aggiuntiva alla fine:

session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid

Il success=1bit significa "se questo modulo ha esito positivo, salta la regola successiva". Solo che non c'è nessuna regola successiva, poiché questa è l'ultima riga nella configurazione di PAM.


Ho avuto la stessa linea (devo averla da qualche parte negli interwebs), l'ho commentata e tutto ha ripreso a funzionare.
Mike,

1

La tua configurazione PAM non è corretta. Questo è comune se hai utilizzato metodi di autenticazione "esterni" come scanner di impronte digitali, account LDAP, chiavi USB o l'ordinamento. Fondamentalmente cron non può funzionare con uno scanner di impronte digitali, quindi non può accedere come te.

Devi rimuovere la configurazione offensiva /etc/pam.d/common-*anche se rintracciarla può essere un po 'difficile, specialmente se non hai abilitato qualcosa manualmente (ad esempio se uno script di installazione dello scanner di impronte digitali ha attivato qualcosa).

Non posso fare molto per dirti cosa dovrebbe essere in quei file. Molte cose potrebbero essere diverse a seconda della configurazione. Ma disabilitare i metodi di autenticazione "richiesti" fino alla tua sinistra con solo "Autenticazione Unix" può essere un buon primo passo.

Puoi farlo eseguendo pam-auth-updatecome root e deselezionando le altre caselle. Fai molta attenzione poiché questo può lasciarti con un sistema a cui non puoi accedere se eseguito in modo errato. Disabilitarli uno alla volta, riavviare per sicurezza e testare. MAI DISATTIVARE "Autenticazione Unix"


Dovrei essere chiaro, uno scanner di impronte digitali dovrebbe normalmente essere "opzionale", non "richiesto". Renderlo "obbligatorio" significa che le cose senza la tua impronta digitale non possono "accedere". A causa di un errore di configurazione come quello potresti finire con un problema come questo. Tuttavia, normalmente uno scanner di impronte digitali (o USB o LDAP o SMB o altro) non causerebbe il problema.
Coteyr,

Non ho collegato scanner di impronte digitali o unità USB. Sai forse da qualche parte che posso verificare quale sarebbe il contenuto predefinito di /etc/pam.d/common-*?
l0b0,

sudo dpkg-reconfigure pamè il modo migliore . Tuttavia, è possibile utilizzare sudo dpkg -i --force-confmissdopo aver eliminato il file (CAREFUL) e verrà ripristinato vedere questo link: superuser.com/questions/69045/…
coteyr,

/usr/sbin/dpkg-reconfigure: pam is not installed. Ho anche provato sudo dpkg-reconfigure libpam-runtime, ma questo non ha aiutato.
l0b0,

1
Non credo sia un pacchetto mancante. Penso che sia una confusione confusa. L'errore "PAM bad jump nello stack" significa che, per qualche motivo, un modulo pam richiesto non è stato in grado di autenticarsi. Come ho già detto, questo è normalmente causato da persone che scherzano con i loro file pam in modo consapevole o accidentale e aggiungono un modulo richiesto che non funziona. Alcuni esempi potrebbero essere l'autenticazione SMB, l'autenticazione LDAP, l'autenticazione basata su hardware, ecc. Tenere presente che alcuni pacchetti potrebbero aver aggiunto un file che causa il problema. Pam funziona, perché puoi accedere, ma non funziona anche perché cron non può
Coteyr,

1

Stavamo cercando di pianificare cron da un utente LDAP (utente non macchina) e ottenere lo stesso permission deniedanche inserendo echocomandi o script di base crontab, mentre funzionava completamente file dagli utenti macchine (che hanno voci in / etc / passwd). Prendendo aiuto dai commenti dettagliati sulla risoluzione dei problemi aggiunti da OP, abbiamo controllato il file in /var/log/auth.logcui abbiamo trovato questa riga:

pam_sss(cron:account): Access denied for user my_username: 6 (Permission denied)

Un po 'di ricerca su Google mi ha portato a questa risposta che ha funzionato per noi. Aggiungendo i dettagli anche qui.

Nel /etc/sssd/sssd.confnostro dominio abbiamo aggiunto una voce (vedi ultima riga) come questa.

[domain/my.domain.com]
....
ad_gpo_map_interactive = +cron

E poi appena fatto sudo service sssd restarte funziona come un fascino.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.