Home/xxx is not ours !

wanica · 08-02-2017 18:48:41

EDIT: titre changé c'est OURS et pas YOURS !

J'obtiens (sur une seule de mes machines et une seule distrib) le message
Home directory /home/<mon user> not ours.

J'ai effectivement bricolé pour remettre un home (qui appartenait à un autre système) sur une partition dédiée plus grande, qui n' avait pas été utilisée lors de l' install qui elle avait été faite sur un home sur une partition assez petite.

Je ne me rappelle plus de ce que j' ai bricolé alors.
J'avais pris garde à mettre le même user et le même mot de passe.

J'ai beau avoir cherché depuis des mois, je n' ai rien trouvé de convaincant comme explication.

Je sais aussi que c'est le seul sytème que j'ai qui ne reconnait plus la connection réseau automatique dès que je change de box.
Je dois éditer manuellement resolv.conf...

sudo gedit /etc/resolv.conf

Le résolv. conf est en principe re créé automatiquement , mais ça ne se passe pas comme ça (ub 12.04).
Je sais que ça ne vient pas de la distrib, mais sans doute de ma manip.

J'ai fouillé dans fstab, checké les UUID, etc, etc, les droits, le montage auto des partitions et je ne comprends pas ce qui se passe.

Là je pense clairement être clairement dans le domaine de compétences de icecat !! Non ?

En attendant je teste ça
https://www.cyberciti.biz/faq/howto-cha … directory/

  finger <mon user>

Et ça ne donne rien de plus que ce que je sais déjà...

IceCat · 08-02-2017 23:49:18

Effectivement ça devrait être dans mes cordes, mais difficile de travailler à l’aveugle...

Pour moi c'est un problème de droits.

T'as fait un

chown -R tonUser:tonUser /home/tonUser/

?

Si ça change rien, je peux voir ton fstab ?

wanica · 09-02-2017 09:54:08

en mode user, la commande ne fonctionne pas, ni précédée de sudo
alors j' ai fait sudo -i

et voici la réponse:

chown: impossible d'accéder à «/home/user/.gvfs»: Permission non accordée

Une recherche me donne:
https://forum.ubuntu-fr.org/viewtopic.php?id=1627711, mais aussi

https://forums.opensuse.org/showthread. … ed-on-gvfs

permission denied on .gvfs buckeyered80 wrote:

> This /home/$USER/.gvfs file is impossible to take ownership of or change permissions on.
I actually wanted to take ownership of my home folder to test a program that won't run, and this untouchable .gvfs folder is in the way. Funny...I think this is a "well-know" bug, reported several times. So, maybe still not fixed:
***
Bug 467862 - By opening firefox a file ".gvfs" are created in the home
direcotry with no access rights
https://bugzilla.novell.com/show_bug.cgi?id=467862

Bug 368628 - gvfs: Random crashes
https://bugzilla.novell.com/show_bug.cgi?id=368628
***

https://forum.ubuntu-fr.org/viewtopic.php?id=1627711
Terminal : permission non accordée .gvfs pour chown ou chmod

 ls -ld ~/.gvfs

 dr-x------ 2 user user 0 févr.  9 08:19 /home/user/.gvfs

  stat .gvfs

  Fichier : «.gvfs»
   Taille : 0         	Blocs : 0          Blocs d'E/S : 4096   répertoire
Périphérique : 15h/21d	Inœud : 1           Liens : 2
Accès : (0500/dr-x------)  UID : ( 1000/     user)   GID : ( 1000/     user)
Accès : 2017-02-09 08:19:22.000000000 +0100
Modif. : 2017-02-09 08:19:22.000000000 +0100
Changt : 2017-02-09 08:19:22.000000000 +0100
  Créé : -

Le test sur la même machine, mais en partition sda4 Ubuntu 12.04 installé en une seule partition avec home donne rigoureusement la même sortie à la différence des heures, minutes de consultation.

 ls -ld ~/.gvfs
dr-x------ 2 clone clone 0 févr.  9 10:23 /home/clone/.gvfs

  stat .gvfs

clone@clone-ThinkPad-R50e:~$ stat .gvfs
Fichier : «.gvfs»
Taille : 0 Blocs : 0 Blocs d'E/S : 4096 répertoire
Périphérique : 13h/19d Inœud : 1 Liens : 2
Accès : (0500/dr-x------) UID : ( 1000/ clone) GID : ( 1000/ clone)
Accès : 2017-02-09 10:23:40.000000000 +0100
Modif. : 2017-02-09 10:23:40.000000000 +0100
Changt : 2017-02-09 10:23:40.000000000 +0100
Créé : -

Sur une autre machine Lubuntu 14.04 sur T61 Lenovo je n' ai pas ce ./gvfs

Sur une autre machine R50 avec lubuntu 14.04 d'installé (sans autres distribs) et avec home séparé et (dual boot windows)

J'ai tout à fait une autre sortie. en drwx et codes 700 au lieu de 500.

 ls -ld ~/.gvfs      
 drwx------ 2 user user 4096 oct.  21  2011 /home/user/.gvfs

et stat .gvfs

 Fichier : «.gvfs»
   Taille : 4096      	Blocs : 8          Blocs d'E/S : 4096   répertoire
Périphérique : 806h/2054d	Inœud : 130340      Liens : 2
Accès : (0700/drwx------)  UID : ( 1000/ user)   GID : ( 1000/ user)
Accès : 2015-04-06 08:29:37.644516843 +0200
Modif. : 2011-10-21 07:04:25.298348234 +0200
Changt : 2011-10-21 07:04:25.298348234 +0200
  Créé : -

La différence tient elle à la distrib, c'est possible.

Notons que sur la machine qui pose souci, j' ai upgradé d'une 10.04 à une 12.04 NON PAE...

Une piste ?

https://forum.ubuntu-fr.org/viewtopic.php?id=216234

Thunar et GNOME Virtual File System ont des problèmes, et pas que sur ubuntu. La solution, trouvé via cet conversation.
La solution, saisir cette commande, en user simple (sans sudo)

     fusermount -u ~/.gvfs

Ce qui remonte le système de fichier virtuel, proprement pour que thunar fonctionne sans souci.
Plus de détails ici(en). Tésté sur Ubuntu 12.04, migré en Xubuntu.

http://r3dux.org/2011/08/how-to-workaro … ed-errors/

ET ÇA MARCHE !! (Sur sda4 clone)
rebootons sur sda 6

La modif fonctionne , à savoir que gvfs ne perturbe plus la commande chown

chown -R tonUser:tonUser /home/tonUser/

Par contre, j'ai toujours

sudo gedit /etc/resolv.conf
Home directory /home/user not ours.

Faut il rebooter ? Testons !

Au reboot rien de changé.
Voyons donc le contenu de fstab comme conseillé plus haut par icecat

https://doc.ubuntu-fr.org/mount_fstab#le_fichier_fstab

UUID=167091B670919D55 /media/data ntfs-3g defaults 0 0
UUID=2e611cf3-e0bc-4ecc-8948-f1cd031e1db3 swap swap sw 0 0
UUID=ddfbc73d-a5f9-4a50-99aa-5e4c9e7bd3ec / ext4 defaults 0 1
UUID=9e412a29-f434-470e-9022-53353acd8346 /home ext4 defaults 0 2
UUID=6d45fca4-da00-4923-b5c7-5d6991680cde /media/clone ext4 defaults 0 0
UUID=908f651e-c899-4c49-bd2e-601320c2fc0f /media/data_ext4 ext4 defaults 0 0

Je ne vois pas d' erreur dans ce fichier fstab l 'option defaults doit suffire partout.

Cf article doc icaunux :
http://icaunux.org/doku.php?id=montage_ … ermissions

Par contre une bizarrerie m' interpelle. la commende free depuis le système me donne un swap de
5144820 soit 5 144 820
alors qu'en mode recovery, la console me donne plutôt 4 xxxx xxxx. Gênant !
Je ne peux donner la valeur précise car je ne sais pas comment communiquer en ligne de commande depuis la console recovery vers un support en écriture ou vers le web...

IceCat · 11-02-2017 12:22:42

C'est une mauvaise idée de lancer une application graphique (gedit) via sudo, car cela lui donne les droits root.

Une rapide recherche me dit qu'il faut utiliser "gksu gedit" à la place de gedit tout court, ce qui est censé utiliser gedit avec les droits sudo de ton profil utilisateur.

Est-ce que l'ouverture de ton ficher /etc/resolv.conf en ligne de commande avec un éditeur texte comme nano ou vi/vim fonctionne ?
Si oui, c'est plus un problème de gedit qu'un problème de droits système.

wanica · 11-02-2017 12:57:53

IceCat a écrit :

C'est une mauvaise idée de lancer une application graphique (gedit) via sudo, car cela lui donne les droits root.

Ah ben ! Mais mes autres machines sur lesquelles j' entre cette commande dangereuse ne se plaignent pas.

Bon, je vais faire l' effort de modifier mes habitudes avec gksu <commande>
donc gksu gedit ouvre une petite fenëtre avec demande de mot de passe.
Le terminal ne se plaint pas.

ça fonctionne aussi avec vi et nano...
dont je ne me souviens pas du mode d'édition ça se rentre avec quel caractère ce bidule ^x ?

wanica · 18-02-2023 18:51:06

Du mauvais usage de chown appliqué inconsidérément au répertoire racine

chown = changer le propriétaire et chmod = changer les droits. Dans les infos pêchées sur les fora, telle que rapportées ci dessous, on trouve pas mal de chmod
https://www.leshirondellesdunet.com/chmod-et-chown

L'avantage du CHown
Pour éviter des chmod 666 (ou pire encore des 777), CHown permet de modifier le propriétaire d'un fichier.Par exemple, si vous souhaitez vous réapproprier les droits sur l'ensemble d'un dossier et que vous êtes l'utilisateur "martin", lancez dans la console :
sudo chown -R martin /chemin/vers/dossier
Puis pour récupérer les droits sur l'ensemble du dossier, lancez :
sudo chmod -R 755 /chemin/vers/dossier

On voit bien que ces commandes sont liées car elles disent qui peut lire écrire ou exécuter un fichier, ces droits étant naturellement attribués ( en tout ou partie) à un utilisateur défini.

sudo chown -R monuser:monuser /

Commande arrêtée avec CTRL+ C, mais les dégâts ont été faits.

Ceci fait toute commande avec sudo donne

sudo: /usr/bin/sudo doit être la propriété du uid 0 et avoir le bit setuid mis

https://www.debian-fr.org/t/sudo-usr-bi … is/83133/8
Nota: le document est incomplet. (Réponse de Bruno qui oublie rw...)
Moi, j'ai ça:

ls -l /usr/bin/sudo /bin/su

-rwsr-xr-x 1 root   root    44664 nov.  29 13:25 /bin/su

-rwxr-xr-x 1 monuser monuser 149080 janv. 16 15:40 /usr/bin/sudo

Erreur ligne ci dessus ? Ce n'est pas monuser monuser mais root root (constaté sur une config saine)
Commande pour remettre les bons droits:

~$ chmod u+s /usr/bin/sudo /bin/su

ne fonctionnera (en fait pas du tout) qu'avec une certaine manip, celle décrite plus bas...avec init

Pour rétablir les permissions ou le propriétaire de sudo ou su, il faut obtenir les privilèges root d’une façon ou d’une autre, par exemple :

en se connectant directement avec le compte root s’il a un mot de passe valide (moralité : toujours définir un mot de passe valide pour le compte root pour se dépanner en cas de problème)
en démarrant le noyau avec init=/bin/bash
en démarrant un autre système (live, installateur…)
==========================================
INIT BIN BAsH
Obtenir un shell root au démarrage
en démarrant le noyau avec init=/bin/bash
On obtient directement un shell root. Ce qui doit permettre de remettre les bon droits d’accès sur su et sudo :

chmod u+s /usr/bin/sudo /bin/su
Pour mon cas, la procédure échoue, au redémarrage rien de changé.

======OPT =======
Autre correction à faire pour mon bug perso.
avec un sudo ls -l dans le répertoire racine ( root /), on voit le détail des fichiers et dossiers.
opt est à présent la propriété de monuser alors que c'est root "qui le possède"
depuis le shell root

  chown -R root:root /opt

Ça, ça marche !

https://memo-linux.com/grub2-contourner … ot-oublie/

init=/bin/bash
est un paramètre à passer au noyau au moment du démarrage. Dans le menu de GRUB, tu peux le faire avec la touche « e » (edit) et ajouter init=/bin/bash (et aussi rw à la place de ro !!!!) à la fin de la ligne commençant par « linux », puis Ctrl+x pour démarrer.

Précision, c'est à la fin de la ligne « linux /vmlinuz-***
Remplacer « ro » par « rw » et aller à la fin de la ligne pour ajouter init=/bin/bash

https://stackoverflow.com/questions/166 … 9#19306929

This problem is caused sometimes when the permissions of the file, /usr/bin/sudo get set to 777. If you do something like chmod -R 777 /usr/, you can do this. It effectively ruins sudo. Here is the solution if this is your problem, and the accepted answer doesn't work: To fix:

Restart pc, press shift at boot menu.

This should bring up GNU GRUB (ie recovery mode) menu.

If this doesn't work, just restart mid boot and choose recovery mode when prompted on next launch.
Select the line which starts with Advanced options
Select the topmost version of the OS ending with ("recovery mode")
Press enter
In the following menu, go down to "Drop to root shell prompt"
Type the following:

mount -o remount,rw /

mount --all

chown root:root /usr/bin/sudo

chmod 4755 /usr/bin/sudo

restart this should restore sudo privellages.

https://askubuntu.com/questions/452860/ … id-bit-set

Note that this will resolve the titular error /usr/bin/sudo must be owned by uid 0 and have the setuid bit set but if like the OP (openstack forum) you did more than mess up the permissions of the /usr/bin/sudo file, a more "nuclear" option may in fact make more sense.

Vu que tu as fait plus que de bousiller les permissions de sudo, un choix plus radical (réinstaller) peut être plus efficace...
Had same problem in my lxc container, additionally had to do this: chown root:root /usr/lib/sudo/sudoers.so && chmod 4755 /usr/lib/sudo/sudoers.so; chown root:root /etc/sudoers; chown root:root /etc/sudoers; –
Aurelijus Rozenas
Jul 12, 2016 at 5:40

https://askubuntu.com/questions/452860/ … id-bit-set

oli a écrit :

If you've only changed the permissions on /usr/bin/sudo, by all means, just fix that. But this question is about a total system change. Every file (save the runtime-only ones) are now owned by the user. Everything the user runs (eg browsers, browser exploits) could then overwrite system files, spy on you, extract any data. This needs to be corrected. Per above, this is difficult. The easiest way is a reinstall.
So please, don't be lazy about this. Filesystem permissions help keep you safe, fix them
edited Nov 21, 2017 at 10:31

Liens ci-dessus à partir du fofo ubuntu https://forum.ubuntu-fr.org/viewtopic.php?id=1813551
https://doc.ubuntu-fr.org/utilisateurs/ … ilisateurs
===================
ce que j'ai fait: Mettre un mot de passe root
Dans un premier temps, pour récupérer quelque chose, créer un mot de passe root qui n'en avait pas sous ubuntu ! A l' ancienne pour les purs et durs de Debian et assimilés.Puis

 password root

Déconseillé par Ubuntu cf
https://doc.ubuntu-fr.org/utilisateurs/ … ilisateurs

Le « super-utilisateur » ayant TOUS les droits sur le système, son utilisation peut être TRÈS dangereuse, pour plusieurs raisons :
Une manipulation dangereuse de votre part. Il est possible que vos manipulations ça aboutisse au dérèglement d'une partie du système. Soyez toujours certain du résultat attendu de vos commandes avant de les lancer.
Une erreur de votre part. Même pour une manipulation supposée sans risque, la moindre faute de frappe dans les commandes peut aboutir à de graves problèmes.

En fait avec sudo, on peut faire les mêmes bêtises !! Argument non valable !!

Du code malveillant. Si vous exécutez un programme ou un script malveillant avec les droits de super-utilisateur, celui-ci n'aura aucun mal à prendre le contrôle du système en totalité et à s'implanter en profondeur dans le système.
Sur les systèmes utilisant Xorg, faire cohabiter les fenêtres de l'utilisateur avec ceux du super-utilisateur au sein de la même session représente une faille de sécurité potentielle, qui a en partie motivée la création de Wayland. C'est entre autres pourquoi il est déconseillé de lancer des programmes graphiques avec sudo.

Bof, pas convaincu !
=======================================
Quitter proprement le shell root ?

exit ou ctrl + d crée un kernel panic

Attempted to kill init

https://www.linuxjournal.com/content/re … -magic-way

Wouldn't it be nice if there was a way to ask the kernel to reboot without needing to access the failing drive? Well, there is a way, and it is remarkably simple.

==== Touches magiques ===
Très utilisées à titre perso depuis ubuntu 10.04 sur ibm R51 qui possède cette touche sur le clavier !

The "magic SysRq key" provides a way to send commands directly to the kernel through the /proc filesystem. It is enabled via a kernel compile time option, CONFIG_MAGIC_SYSRQ, which seems to be standard on most distributions. First you must activate the magic SysRq option:

 echo 1 > /proc/sys/kernel/sysrq

When you are ready to reboot the machine simply run the following:

    echo b > /proc/sysrq-trigger

This does not attempt to unmount or sync filesystems, so it should only be used when absolutely necessary, but if your drive is already failing then that may not be a concern.

======
Autre façon de sortir du shell init bash ??
=======
https://www.linuxquestions.org/question … sh-440509/

By the way, when you do init=/bin/sh (or bash), it isn't strictly necessary to reboot afterwards (well, depending on what you change I suppose), you can just do an 'exec /sbin/init' to continue the boot process. Make sure the state of the system is as it would normally be though (e.g. umount /usr, make / readonly again etc).

exec /sbin/init

https://en.wikipedia.org/wiki/Magic_SysRq_key

Sous Ubuntu c'est 176

nano /etc/sysctl.d/10-magic-sysrq.conf

Wikipedia a écrit :

Before the advent of journaled filesystems a common use of the magic SysRq key was to perform a safe reboot of a Linux computer which has otherwise locked up (abbr. REISUB), which avoided a risk of filesystem corruption. With modern filesystems, this practice is not encouraged, offering no upsides over straight reBoot,[6] though the default value of kernel.sysrq in such distributions as Ubuntu and Debian remains 176 and 438 [7] respectively.

Fn+S Has the same function as the SysRq key on a conventional keyboard. (TP X230)
=================================
Autre piste:
https://askubuntu.com/questions/452860/ … id-bit-set

Certains écrivent qu'il faut à tout prix réinstaller, d'autres que la manip est possible avec un compte root (cf debian avant), ou bien depuis le mode recovery de grub...

wanica · 22-02-2023 10:55:48

Mode recovery, (menu de grub)
Mettre à jour grub, qui met en mode écriture le système, puis Root: on est en console
entrer les commandes telles que ls -l pour vérifier user ou root fait défiler tout l' écran.

penser à ajouter un pipe avec less

ls -l  | less

De nombreux fichiers système ont été attribués à user:user au lieu de root:root

Le mode recovery ne fonctionne pas pour modifier les droits !

Si l'on a pris la peine de créer un mot de passe root, se logguer graphiquement (internet coupé) dans une session root permet de modifier graphiquement les droits chown sur les dossiers.

Ceci dit, le setuid n'est pas modifié pour autant.

Un gparted dans le terminal, au lieu de lancer la console graphique d'élèvation de privilèges renvoie

pkexec must be setuid root

wanica · 22-02-2023 14:15:31

Rappel: lien vers doc Icaunux:
https://www.icaunux.org/doku.php?id=dro … s_dossiers

suid

La doc ubuntu renvoie à wikipedia !
https://fr.wikipedia.org/wiki/Setuid

wikipedia a écrit :

En pratique Il est possible de voir si un fichier est setuid ou setgid en tapant la commande :
$ ls -l nom_du_fichier  
-rwsr-sr-x 1 propriétaire groupe 158998 mars 12 17:12 nom_du_fichier
Le s dans la première partie (réservée au propriétaire) -rws indique que le fichier est setuid, le s dans la deuxième partie (réservée au group) r-s indique que le fichier est setgid. Si le s est en minuscule c'est que le fichier est exécutable par contre s'il est majuscule c'est qu'il n'est pas exécutable.
Il est également possible de lister tous les fichiers setuid et setgid du système grâce à la commande find / -type f -perm /6000 -ls 2>/dev/null2.

pkexec se trouve dans /usr/bin

Pour activer le setuid

 chmod  u+s nom_du_fichier  # pour activer le Setuid

Oui, mais !
Le mode sudo ne fonctionne pas.
Le mode su - idem

Solution : mode graphique, se délogguer, puis se logguer en root

Config saine les droits sur pkexec sont rwsr-xr-x
Config daubée wsr-xr-x

Le log graphique en root donne cet avertissement:
Error found when loading /root/.profile

Le log graphique ne permet pas de modifier le bit setuid ! Seul le log (avec rw) init=//bin/bash permet la modification ! Mais celle-ci n'est en fait pas conservée ?!!

wanica · 22-02-2023 15:56:23

https://fr.linux-console.net/?p=564#gsc.tab=0
Dans ce didacticiel, nous expliquerons les autorisations sur les fichiers auxiliaires, communément appelées « autorisations spéciales » sous Linux, et nous vous montrerons également comment rechercher des fichiers portant le SUID ( Setuid) et SGID (Setgid).

SUID est une autorisation de fichier spéciale pour les fichiers exécutables qui permet à d'autres utilisateurs d'exécuter le fichier avec les autorisations effectives du propriétaire du fichier. Au lieu du x qui représente les autorisations d'exécution, vous verrez une autorisation spéciale s (pour indiquer SUID ) à l'utilisateur.

SGID est une autorisation de fichier spéciale qui s'applique également aux fichiers exécutables et permet aux autres utilisateurs d'hériter du GID effectif du propriétaire du groupe de fichiers. De même, plutôt que l'habituel x qui représente les autorisations d'exécution, vous verrez une autorisation spéciale s (pour indiquer SGID ) pour l'utilisateur du groupe.

Voyons comment trouver les fichiers dont les SUID et SGID sont définis à l’aide de la commande find.

La syntaxe (NDR NE FCT PAS !!) est la suivante:

 $ find directory -perm /permissions

rouge (apparaît en rouge dans le terminal !)
Ne fonctionne pas en mode init ! Ni en graphique

find: mode non valide « ‘/permission’

find / perm

liste beaucoup trop de fichiers pour que cela soit lisible !
https://fr.linux-console.net/?p=564#gsc.tab=0
Cet exemple de commande ci-dessous trouvera tous les fichiers avec SUID dans le répertoire en cours à l’aide de l’option -perm

$ find . -perm /4000

recherche les fichiers d'impression uniquement avec les autorisations définies sur 4000

$ find . -perm /2000

recherche les fichiers pour lesquels SGID est défini,

$ find . -perm /6000

rechercher les fichiers contenant SUID et SGID

Edit suite d'un autre post
zram, swap sur partition dédiée...lorsque désactivé au profit de zram, cela peut créer
des soucis lors du boot temps d'attente long...et entre temps on peut avoir modifié le swap ( créé, ou supprimé la partition)

trouver le nouvel uuid

 sudo blkid

l' ajouter à fstab

sudo nano /etc/fstab

et à initramfs

sudo nano /etc/initramfs-tools/conf.d/resume

Mettre à jour initramfs

sudo  update-initramfs -k all -u

Icaunux - Le Forum

Annonce

#1 08-02-2017 18:48:41

Home/xxx is not ours !

#2 08-02-2017 23:49:18

Re : Home/xxx is not ours !

#3 09-02-2017 09:54:08

Re : Home/xxx is not ours !

#4 11-02-2017 12:22:42

Re : Home/xxx is not ours !

#5 11-02-2017 12:57:53

Re : Home/xxx is not ours !

#6 18-02-2023 18:51:06

Re : Home/xxx is not ours !

#7 22-02-2023 10:55:48

Re : Home/xxx is not ours !

#8 22-02-2023 14:15:31

Re : Home/xxx is not ours !

#9 22-02-2023 15:56:23

Re : Home/xxx is not ours !

Pied de page des forums