▲ 684 ▼ You can't cd or ls in a folder if you have no +x permissions on it. That is all. I wasted 3 hours of my life. (szmer.info) submitted 2 years ago by unsaid0415@szmer.info to c/linux@lemmy.ml 122 comments fedilink hide all child comments
[–] THE_STORM_BLADE@lemmy.world 51 points 2 years ago (3 children) For anyone that didn't recognise this as a joke, do not do this! permalink fedilink source parent hideshow 6 child comments replies: [–] DogMuffins@discuss.tchncs.de 8 points 2 years ago (1 child) Oh. Ok. Should I undo it then? permalink fedilink source parent hideshow 2 child comments replies: [–] redprog@feddit.de 13 points 2 years ago Yeah just hit Ctrl + Z and you should be fine permalink fedilink source parent [–] Synthead@lemmy.world 6 points 2 years ago (1 child) Yup, this will pretty much destroy your system. permalink fedilink source parent hideshow 2 child comments replies: [–] SorteKanin@feddit.dk 2 points 2 years ago (3 children) Actually curious how though - I mean won't it just let all programs/users access everything? Or do some system stuff rely on permissions for certain behavior? permalink fedilink source parent hideshow 6 child comments replies: [–] savedbythezsh@sh.itjust.works 4 points 2 years ago SSH will definitely break, I've had this issue before. If your private key in the .ssh dir is too open, ssh won't let you use it. permalink fedilink source parent [–] palordrolap@kbin.social 3 points 2 years ago (1 child) Theoretically yes, but yes, in that order. I've worked with Linux for decades at this point and I'm still not 100% sure exactly what breaks; it's a mistake you make once, if at all, and you'll only get a little way into even trying to figure out how to fix things before you throw your hands up in disgust and reinstall / restore the OS (or whatever subdir was affected). If I was to hazard a guess, it's the kernel itself that balks, but there are other, almost as fundamental things (lib*.so files and the like) that may also be deliberately fussy. permalink fedilink source parent hideshow 2 child comments replies: [–] nixcamic@lemmy.world 2 points 2 years ago (2 children) I think it's systemd not the kernel. If only Linux had "repair permissions" like vintage MacOS. permalink fedilink source parent hideshow 4 child comments replies: [–] Synthead@lemmy.world 1 point 2 years ago You don't typically have permissions "become defective" or need them to be "repaired" in a Linux system. Nearly all system files, with their permissions, are included in packages. Everything else should be considered user data. If you logged in as root and did something dumb, you could attempt to fix the permissions by reinstating packages. permalink fedilink source parent [–] palordrolap@kbin.social 1 point 2 years ago (1 child) Recursive chmod (or chown) has been breaking things since before systemd was a thing, so even if systemd is now responsible for stopping things from working, it can't have been that previously, especially at the time I might have done something silly. As for repairing permissions only, I suppose it would be possible, assuming the system still works (or can somehow be encouraged to do so) to copy only the permissions (or at least infer them) from a backup or something rather than the whole files. permalink fedilink source parent hideshow 2 child comments replies: [–] nixcamic@lemmy.world 1 point 2 years ago Probably init before that then. I don't think the kernel cares unless explicitly told to care, I've seen some embedded Linux with interesting permissions. permalink fedilink source parent [–] Phrodo_00@lemmy.world 2 points 2 years ago I actually don't know how many programs do this, but several check that file permissions are correct or refuse to work. Sudo and ash are 2 of them. I could see /etc/shadow being readable and writable by everyone being a problem too, but I don't know. permalink fedilink source parent [–] stolid_agnostic@lemmy.ml 1 point 2 years ago (1 child) Edit removed it. What was it? permalink fedilink source parent hideshow 2 child comments replies: [+] neonred@lemmy.world 1 point 2 years ago* (last edited 1 year ago) [deleted] permalink fedilink source parent
[–] DogMuffins@discuss.tchncs.de 8 points 2 years ago (1 child) Oh. Ok. Should I undo it then? permalink fedilink source parent hideshow 2 child comments replies: [–] redprog@feddit.de 13 points 2 years ago Yeah just hit Ctrl + Z and you should be fine permalink fedilink source parent
[–] redprog@feddit.de 13 points 2 years ago Yeah just hit Ctrl + Z and you should be fine permalink fedilink source parent
[–] Synthead@lemmy.world 6 points 2 years ago (1 child) Yup, this will pretty much destroy your system. permalink fedilink source parent hideshow 2 child comments replies: [–] SorteKanin@feddit.dk 2 points 2 years ago (3 children) Actually curious how though - I mean won't it just let all programs/users access everything? Or do some system stuff rely on permissions for certain behavior? permalink fedilink source parent hideshow 6 child comments replies: [–] savedbythezsh@sh.itjust.works 4 points 2 years ago SSH will definitely break, I've had this issue before. If your private key in the .ssh dir is too open, ssh won't let you use it. permalink fedilink source parent [–] palordrolap@kbin.social 3 points 2 years ago (1 child) Theoretically yes, but yes, in that order. I've worked with Linux for decades at this point and I'm still not 100% sure exactly what breaks; it's a mistake you make once, if at all, and you'll only get a little way into even trying to figure out how to fix things before you throw your hands up in disgust and reinstall / restore the OS (or whatever subdir was affected). If I was to hazard a guess, it's the kernel itself that balks, but there are other, almost as fundamental things (lib*.so files and the like) that may also be deliberately fussy. permalink fedilink source parent hideshow 2 child comments replies: [–] nixcamic@lemmy.world 2 points 2 years ago (2 children) I think it's systemd not the kernel. If only Linux had "repair permissions" like vintage MacOS. permalink fedilink source parent hideshow 4 child comments replies: [–] Synthead@lemmy.world 1 point 2 years ago You don't typically have permissions "become defective" or need them to be "repaired" in a Linux system. Nearly all system files, with their permissions, are included in packages. Everything else should be considered user data. If you logged in as root and did something dumb, you could attempt to fix the permissions by reinstating packages. permalink fedilink source parent [–] palordrolap@kbin.social 1 point 2 years ago (1 child) Recursive chmod (or chown) has been breaking things since before systemd was a thing, so even if systemd is now responsible for stopping things from working, it can't have been that previously, especially at the time I might have done something silly. As for repairing permissions only, I suppose it would be possible, assuming the system still works (or can somehow be encouraged to do so) to copy only the permissions (or at least infer them) from a backup or something rather than the whole files. permalink fedilink source parent hideshow 2 child comments replies: [–] nixcamic@lemmy.world 1 point 2 years ago Probably init before that then. I don't think the kernel cares unless explicitly told to care, I've seen some embedded Linux with interesting permissions. permalink fedilink source parent [–] Phrodo_00@lemmy.world 2 points 2 years ago I actually don't know how many programs do this, but several check that file permissions are correct or refuse to work. Sudo and ash are 2 of them. I could see /etc/shadow being readable and writable by everyone being a problem too, but I don't know. permalink fedilink source parent
[–] SorteKanin@feddit.dk 2 points 2 years ago (3 children) Actually curious how though - I mean won't it just let all programs/users access everything? Or do some system stuff rely on permissions for certain behavior? permalink fedilink source parent hideshow 6 child comments replies: [–] savedbythezsh@sh.itjust.works 4 points 2 years ago SSH will definitely break, I've had this issue before. If your private key in the .ssh dir is too open, ssh won't let you use it. permalink fedilink source parent [–] palordrolap@kbin.social 3 points 2 years ago (1 child) Theoretically yes, but yes, in that order. I've worked with Linux for decades at this point and I'm still not 100% sure exactly what breaks; it's a mistake you make once, if at all, and you'll only get a little way into even trying to figure out how to fix things before you throw your hands up in disgust and reinstall / restore the OS (or whatever subdir was affected). If I was to hazard a guess, it's the kernel itself that balks, but there are other, almost as fundamental things (lib*.so files and the like) that may also be deliberately fussy. permalink fedilink source parent hideshow 2 child comments replies: [–] nixcamic@lemmy.world 2 points 2 years ago (2 children) I think it's systemd not the kernel. If only Linux had "repair permissions" like vintage MacOS. permalink fedilink source parent hideshow 4 child comments replies: [–] Synthead@lemmy.world 1 point 2 years ago You don't typically have permissions "become defective" or need them to be "repaired" in a Linux system. Nearly all system files, with their permissions, are included in packages. Everything else should be considered user data. If you logged in as root and did something dumb, you could attempt to fix the permissions by reinstating packages. permalink fedilink source parent [–] palordrolap@kbin.social 1 point 2 years ago (1 child) Recursive chmod (or chown) has been breaking things since before systemd was a thing, so even if systemd is now responsible for stopping things from working, it can't have been that previously, especially at the time I might have done something silly. As for repairing permissions only, I suppose it would be possible, assuming the system still works (or can somehow be encouraged to do so) to copy only the permissions (or at least infer them) from a backup or something rather than the whole files. permalink fedilink source parent hideshow 2 child comments replies: [–] nixcamic@lemmy.world 1 point 2 years ago Probably init before that then. I don't think the kernel cares unless explicitly told to care, I've seen some embedded Linux with interesting permissions. permalink fedilink source parent [–] Phrodo_00@lemmy.world 2 points 2 years ago I actually don't know how many programs do this, but several check that file permissions are correct or refuse to work. Sudo and ash are 2 of them. I could see /etc/shadow being readable and writable by everyone being a problem too, but I don't know. permalink fedilink source parent
[–] savedbythezsh@sh.itjust.works 4 points 2 years ago SSH will definitely break, I've had this issue before. If your private key in the .ssh dir is too open, ssh won't let you use it. permalink fedilink source parent
[–] palordrolap@kbin.social 3 points 2 years ago (1 child) Theoretically yes, but yes, in that order. I've worked with Linux for decades at this point and I'm still not 100% sure exactly what breaks; it's a mistake you make once, if at all, and you'll only get a little way into even trying to figure out how to fix things before you throw your hands up in disgust and reinstall / restore the OS (or whatever subdir was affected). If I was to hazard a guess, it's the kernel itself that balks, but there are other, almost as fundamental things (lib*.so files and the like) that may also be deliberately fussy. permalink fedilink source parent hideshow 2 child comments replies: [–] nixcamic@lemmy.world 2 points 2 years ago (2 children) I think it's systemd not the kernel. If only Linux had "repair permissions" like vintage MacOS. permalink fedilink source parent hideshow 4 child comments replies: [–] Synthead@lemmy.world 1 point 2 years ago You don't typically have permissions "become defective" or need them to be "repaired" in a Linux system. Nearly all system files, with their permissions, are included in packages. Everything else should be considered user data. If you logged in as root and did something dumb, you could attempt to fix the permissions by reinstating packages. permalink fedilink source parent [–] palordrolap@kbin.social 1 point 2 years ago (1 child) Recursive chmod (or chown) has been breaking things since before systemd was a thing, so even if systemd is now responsible for stopping things from working, it can't have been that previously, especially at the time I might have done something silly. As for repairing permissions only, I suppose it would be possible, assuming the system still works (or can somehow be encouraged to do so) to copy only the permissions (or at least infer them) from a backup or something rather than the whole files. permalink fedilink source parent hideshow 2 child comments replies: [–] nixcamic@lemmy.world 1 point 2 years ago Probably init before that then. I don't think the kernel cares unless explicitly told to care, I've seen some embedded Linux with interesting permissions. permalink fedilink source parent
[–] nixcamic@lemmy.world 2 points 2 years ago (2 children) I think it's systemd not the kernel. If only Linux had "repair permissions" like vintage MacOS. permalink fedilink source parent hideshow 4 child comments replies: [–] Synthead@lemmy.world 1 point 2 years ago You don't typically have permissions "become defective" or need them to be "repaired" in a Linux system. Nearly all system files, with their permissions, are included in packages. Everything else should be considered user data. If you logged in as root and did something dumb, you could attempt to fix the permissions by reinstating packages. permalink fedilink source parent [–] palordrolap@kbin.social 1 point 2 years ago (1 child) Recursive chmod (or chown) has been breaking things since before systemd was a thing, so even if systemd is now responsible for stopping things from working, it can't have been that previously, especially at the time I might have done something silly. As for repairing permissions only, I suppose it would be possible, assuming the system still works (or can somehow be encouraged to do so) to copy only the permissions (or at least infer them) from a backup or something rather than the whole files. permalink fedilink source parent hideshow 2 child comments replies: [–] nixcamic@lemmy.world 1 point 2 years ago Probably init before that then. I don't think the kernel cares unless explicitly told to care, I've seen some embedded Linux with interesting permissions. permalink fedilink source parent
[–] Synthead@lemmy.world 1 point 2 years ago You don't typically have permissions "become defective" or need them to be "repaired" in a Linux system. Nearly all system files, with their permissions, are included in packages. Everything else should be considered user data. If you logged in as root and did something dumb, you could attempt to fix the permissions by reinstating packages. permalink fedilink source parent
[–] palordrolap@kbin.social 1 point 2 years ago (1 child) Recursive chmod (or chown) has been breaking things since before systemd was a thing, so even if systemd is now responsible for stopping things from working, it can't have been that previously, especially at the time I might have done something silly. As for repairing permissions only, I suppose it would be possible, assuming the system still works (or can somehow be encouraged to do so) to copy only the permissions (or at least infer them) from a backup or something rather than the whole files. permalink fedilink source parent hideshow 2 child comments replies: [–] nixcamic@lemmy.world 1 point 2 years ago Probably init before that then. I don't think the kernel cares unless explicitly told to care, I've seen some embedded Linux with interesting permissions. permalink fedilink source parent
[–] nixcamic@lemmy.world 1 point 2 years ago Probably init before that then. I don't think the kernel cares unless explicitly told to care, I've seen some embedded Linux with interesting permissions. permalink fedilink source parent
[–] Phrodo_00@lemmy.world 2 points 2 years ago I actually don't know how many programs do this, but several check that file permissions are correct or refuse to work. Sudo and ash are 2 of them. I could see /etc/shadow being readable and writable by everyone being a problem too, but I don't know. permalink fedilink source parent
[–] stolid_agnostic@lemmy.ml 1 point 2 years ago (1 child) Edit removed it. What was it? permalink fedilink source parent hideshow 2 child comments replies: [+] neonred@lemmy.world 1 point 2 years ago* (last edited 1 year ago) [deleted] permalink fedilink source parent
[+] neonred@lemmy.world 1 point 2 years ago* (last edited 1 year ago) [deleted] permalink fedilink source parent