Autorisations pour un script de soumission

Un suivi de l'un des commentaires (je n'ai pas assez de mojo pour commenter encore): il semble que tout le monde ait access à un hôte connu pour effectuer ses tâches. Cela simplifie les choses. Voici ce que vous pouvez (et devriez) faire:

• Vous devriez mettre en place un server git (de preference gitolite pour ce type d'environnement) et un repo séparé pour chaque étudiant. En supposant que vous avez mis en place les directorys de la maison des étudiants, vous pouvez aller de l'avant et exécuter ssh-keygen pour chaque count étudiant et copyr les keys publiques à votre configuration admin gitolite. (EDIT): l'access root n'est pas nécessaire pour installer gitolite. La création de keys publique / privée nécessite l'access à leurs counts, bien sûr, mais une seule command qu'ils peuvent exécuter si nécessaire (ssh-keygen). )
• Chaque étudiant a seulement des permissions pour leur repo, mais vous avez access à lire / écrire à tous.
• Ils clonent leur repo avec les templates initiaux et les instructions au début du cours; ensuite, ils tirent / poussent seulement de nouvelles affectations et soumissions.
• Chaque projet (affectation) peut être dans un directory séparé (comme vous l'avez proposé). Et vous pouvez créer vous-même les directorys et valider / pousser les changements, et ils peuvent simplement tirer les changements quand il est time de démarrer le projet. (Oui, vous devez le faire pour chaque élève, mais cela peut facilement être écrit). De cette façon, vous savez que les directorys du projet sont tous nommés correctement pour prendre en charge l'automation pour le classment.
• Avantages supplémentaires: Vous pouvez voir qui a commencé le projet la nuit avant qu'il soit dû … et qui a commencé tôt et raffiné comme ils sont allés. Points bonus pour les engagements réguliers; less les points pour une seule validation avec le projet "fini". Vous pouvez également (facultativement) faire travailler des équipes et voir qui a fait tout le travail (chaque personne aurait son propre historique de commit). Il est sortingvial de configurer les permissions de cette façon dans gitolite.

Longue histoire courte: il y a tellement de choses à apprendre pour les étudiants, si peu de time pour l'enseigner. Au cours des 20 dernières années en tant que développeur professionnel, j'ai rarement vu une nouvelle embauche de l'université savoir comment utiliser n'importe quel type de contrôle de révision. Tout ce qu'ils ont est une compréhension lâche des langages de programmation x, y & z (et Java), et ne savent rien du développement de logiciels. Mais nous ne pouvons pas vraiment blâmer les étudiants, cependant, pouvons-nous? (Ahem …) C'est un moment d'enseignement.

Pour être complet, voici la solution la plus simple. Je le suis avec mon sharepoint vue sur la raison pour laquelle un système de versionnement n'est pas approprié.

J'ai fini par activer le bit setuid sur l'exécutable de soumission (chmod 4755), de sorte que lorsque les étudiants l'exécutaient, le programme fonctionnait comme moi. Toute copy de files me transférerait alors la propriété, et je pourrais rendre tout le directory inaccessible aux étudiants. Cela a impliqué quelques obstacles pour passer outre la security setuid ajoutée de Perl (désamorçant l'input, désamorçant le PATH), mais cela a bien fonctionné à la fin. Le script final est d'environ 20 lignes.

La raison pour laquelle un système de gestion des versions est inacceptable est qu'il s'agit d'un premier cours de programmation. Les étudiants n'ont jamais utilisé un terminal, et sont assez confus par l'idée de ssh-ing dans un server et le transfert de files en arrière. Les détails d'un système de contrôle de version sont destinés aux classs de la division supérieure (en particulier lorsqu'un élève est sujet à des fautes de frappe!). Et vous seriez surpris aujourd'hui de savoir combien de ces cours exigent un système de contrôle de version (j'ai suivi quatre cours dans mon premier cycle). Une raison less importante pour laquelle je ne pouvais pas faire de système de versioning est que je ne pouvais pas avoir de privilèges de super user sur le server et ne requestrais pas au professeur de mettre en place un système de versionnement juste parce que je ne pouvais pas comprendre le stupide bit setuid.

Tout ce que je veux pour ce cours est une simple soumission en une étape à un endroit privé. Le problème était avec mon exécution et mon manque de connaissance des permissions unix (ne connaissant pas le bit setuid), pas la structure de ma solution. Donc le commentaire de Sean C. était le pourboire, mais je ne l'avais pas reconnu au début car il semblait qu'il voulait dire que le script était exécuté en tant que root, et je ne voulais pas que cela protège le monde de la mienne naivete à propos d'unix.

Voici le script de travail réel, et ses permissions. Veuillez indiquer les trous de security que vous pourriez voir.

-rwsr-xr-x 1 260s12ta 260s12ta 600 2012-01-16 23:19 submit

 #!/usr/bin/perl use File::Copy; $ENV{"PATH"} = "/usr/bin"; # appease the perl-suid security for shell calls my $username = getlogin() or die "Couldn't access user login: $!\n"; my $dir = "/home/260s12ta/labs/$username/"; foreach (@ARGV) { if ($_ =~ /([\w-]+\.tar\.gz)/) { # untaint the given filename $filename = $1; } else { die "\nInvalid submission: $_ is not a .tar.gz file.\n"; } print "Submitting $filename... "; copy($filename, $dir) or print "Submission failed: $!\n"; chmod(0600, "$dir/$filename") or print "Submission failed: $!\n"; print "OK!\n"; } 

Vous devriez être capable d'utiliser le bit Sticky pour permettre aux étudiants de surécrire leurs propres files dans le directory partagé.

Edit: Ne résout pas le problème puisque les étudiants seraient capables de lire le travail des autres étudiants.