Re: Restoring sticky bits after accidentally moving /usr directory
Steve Dondley wrote: ... > Thanks for the offer. However, I fixed the problem by doing: > > "sudo find /usr -perm g=s" and sudo "find /usr -perm u=s" on a known > good install similar to my broken machine. > > Then I manually changed permissions on the broken machine. It didn't > take too long and I could be sure things didn't get too badly screwed up > by doing it manually. There was only about a dozen or so > directories/files that needed to be changed. good to know it wasn't that bad! :) songbird
Re: Restoring sticky bits after accidentally moving /usr directory
On 2021-05-19 06:30 AM, Hans wrote: Am Mittwoch, 19. Mai 2021, 00:26:18 CEST schrieb Steve Dondley: I believe, there is no easy way. However, if interested, I can send you my list of permissions of /var and /usr. These are not changed by me with one exception (/var/log/motion/motion.log, as there is a bug). Please send me your private mailadress when interested, I do not want to send the files into the list here (minimzing possible readers). Maybe somone has the same idea and can create a script to set permissions from an untouched folder to another folder. Dunno, if this is possible at all. Thanks for the offer. However, I fixed the problem by doing: "sudo find /usr -perm g=s" and sudo "find /usr -perm u=s" on a known good install similar to my broken machine. Then I manually changed permissions on the broken machine. It didn't take too long and I could be sure things didn't get too badly screwed up by doing it manually. There was only about a dozen or so directories/files that needed to be changed.
Re: Restoring sticky bits after accidentally moving /usr directory
Hello, On Tue, May 18, 2021 at 11:40:38PM -0400, Greg Wooledge wrote: > On Tue, May 18, 2021 at 11:46:38PM +, Andy Smith wrote: > > I can't think of an easy way if you don't have backups. If you have > > another system you could get a list of all its permissions like so: > > > > # find /usr -xdev -printf '%p %m\0' | sort -z > good-perms > > > > Then on your suspect machine: > > > > # find /usr -xdev -printf '%p %m\0' | sort -z > suspect-perms > > > > And then run this perl script: > > > > https://gist.github.com/grifferz/1c478ea5eb789b2a1d1a3e49d2a9345c > > The serialization format you're using (pathname followed by mode) is > not ideal for parsing. I'd suggest putting the mode *first*, because it's > in a known, fixed format, and then the pathname second. I was wondering about that at the time but it seemed like the end of each item could only ever be a space, a sequence of digits and then \0, so I didn't think it could be a problem. But yeah, not too many changes needed if you want to switch them around. I also realised later that there isn't too much point in sorting the both the file lists. I did that because I was initially going to use the "comm" command, which needs the files to be sorted, but later decided against it. If you are happy with seeing the results in the order that the "suspect-perms" find command outputs them, then just don;t bother sorting either of them. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Restoring sticky bits after accidentally moving /usr directory
Am Mittwoch, 19. Mai 2021, 00:26:18 CEST schrieb Steve Dondley: I believe, there is no easy way. However, if interested, I can send you my list of permissions of /var and /usr. These are not changed by me with one exception (/var/log/motion/motion.log, as there is a bug). Please send me your private mailadress when interested, I do not want to send the files into the list here (minimzing possible readers). Maybe somone has the same idea and can create a script to set permissions from an untouched folder to another folder. Dunno, if this is possible at all. Best Hans > I goofed up and accidentally moved my /usr directory while trying to > make room on a full drive. I was able to recover, but I'm finding that > services are not working because the sticky bits for many files > /usr/bin/* were lost. For example, I can't send email with exim because > of this error: > > Failed to create spool file /var/spool/exim4//input//1lj87g-0002tS-5J-D: > Permission denied > > Is there an easy way to ensure I set all the permissions back to where > they were before I move /usr? signature.asc Description: This is a digitally signed message part.
Re: Restoring sticky bits after accidentally moving /usr directory
On Ma, 18 mai 21, 18:26:18, Steve Dondley wrote: > I goofed up and accidentally moved my /usr directory while trying to make > room on a full drive. I was able to recover, but I'm finding that services > are not working because the sticky bits for many files /usr/bin/* were lost. > For example, I can't send email with exim because of this error: > > Failed to create spool file /var/spool/exim4//input//1lj87g-0002tS-5J-D: > Permission denied > > Is there an easy way to ensure I set all the permissions back to where they > were before I move /usr? Maybe not applicable for /usr, but ACLs and possibly also extended attributes could be an issue as well. I found it out the hard way recently after copying an install with 'rsync -a' between two storage devices (-a doesn't include -H, -A and -X). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Restoring sticky bits after accidentally moving /usr directory
On Wed, 2021-05-19 at 07:42 +0100, Tixy wrote: [...] > When reinstalling packages that were installed automatically to satisfy > dependencies, you would want to make sure their state is set back to > auto installed after forcibly reinstalling them. > > I've not done this sort of thing, but to get and set package states > 'apt-mark' looks like the tool. Try 'man apt-mark'. Actually, searching on the internet there seems to be lots of different suggested methods for 'reinstall all debian packages' and I don't have the experience to recommend any. Though I would certainly want to use a tool to get a record of currently installed packages and their state before doing anything first - so I had a method of checking results and fixing any mess I'd caused. -- Tixy
Re: Restoring sticky bits after accidentally moving /usr directory
On Tue, 2021-05-18 at 20:28 -0400, songbird wrote: > Steve Dondley wrote: > > > I goofed up and accidentally moved my /usr directory while trying to > > make room on a full drive. I was able to recover, but I'm finding that > > services are not working because the sticky bits for many files > > /usr/bin/* were lost. For example, I can't send email with exim because > > of this error: > > > > Failed to create spool file /var/spool/exim4//input//1lj87g-0002tS-5J-D: > > Permission denied > > > > Is there an easy way to ensure I set all the permissions back to where > > they were before I move /usr? > > not that i can think of being super easy, but listing all > packages on the system and then reinstalling each of them > should do it. > > i think... :) I thought that too, but possibly (probably?) package install doesn't setup directory permissions if it already exists. There's no harm trying though, except... When reinstalling packages that were installed automatically to satisfy dependencies, you would want to make sure their state is set back to auto installed after forcibly reinstalling them. I've not done this sort of thing, but to get and set package states 'apt-mark' looks like the tool. Try 'man apt-mark'. -- Tixy
Re: Restoring sticky bits after accidentally moving /usr directory
On Tue, May 18, 2021 at 11:46:38PM +, Andy Smith wrote: > I can't think of an easy way if you don't have backups. If you have > another system you could get a list of all its permissions like so: > > # find /usr -xdev -printf '%p %m\0' | sort -z > good-perms > > Then on your suspect machine: > > # find /usr -xdev -printf '%p %m\0' | sort -z > suspect-perms > > And then run this perl script: > > https://gist.github.com/grifferz/1c478ea5eb789b2a1d1a3e49d2a9345c The serialization format you're using (pathname followed by mode) is not ideal for parsing. I'd suggest putting the mode *first*, because it's in a known, fixed format, and then the pathname second. Obviously this would require changing the script that's doing the parsing, as well as the sort command (e.g. sort -z -k2), but it should be easier that way.
Re: Restoring sticky bits after accidentally moving /usr directory
Steve Dondley wrote: > I goofed up and accidentally moved my /usr directory while trying to > make room on a full drive. I was able to recover, but I'm finding that > services are not working because the sticky bits for many files > /usr/bin/* were lost. For example, I can't send email with exim because > of this error: > > Failed to create spool file /var/spool/exim4//input//1lj87g-0002tS-5J-D: > Permission denied > > Is there an easy way to ensure I set all the permissions back to where > they were before I move /usr? not that i can think of being super easy, but listing all packages on the system and then reinstalling each of them should do it. i think... :) songbird
Re: Restoring sticky bits after accidentally moving /usr directory
On Wed, 19 May 2021 at 08:26, Steve Dondley wrote: > I goofed up and accidentally moved my /usr directory while trying to > make room on a full drive. I was able to recover, but I'm finding that > services are not working because the sticky bits for many files > /usr/bin/* were lost. For example, I can't send email with exim because > of this error: > > Failed to create spool file /var/spool/exim4//input//1lj87g-0002tS-5J-D: > Permission denied > > Is there an easy way to ensure I set all the permissions back to where > they were before I move /usr? This is what I would do. Restore my backup somewhere so that I have a tree with the correct filesystem attributes. Make a temporary copy of the broken /usr tree to somewhere else, in case something goes wrong. Then run: sudo cp --attributes-only --archive /correct/* /broken I tested this just now on a toy example, it seems to work. I suggest to test it yourself before using it, to verify that it does what you need.
Re: Restoring sticky bits after accidentally moving /usr directory
>> are not working because the sticky bits for many files /usr/bin/* were lost. >> For example, I can't send email with exim because of this error: >> >> Failed to create spool file /var/spool/exim4//input//1lj87g-0002tS-5J-D: >> Permission denied > > I'm guessing you actually mean setuid/setgid bit, not sticky bit. Sorry yeah. Setuid/gid. > >> Is there an easy way to ensure I set all the permissions back to where they >> were before I move /usr? > > I can't think of an easy way if you don't have backups. If you have > another system you could get a list of all its permissions like so: > > # find /usr -xdev -printf '%p %m\0' | sort -z > good-perms > > Then on your suspect machine: > > # find /usr -xdev -printf '%p %m\0' | sort -z > suspect-perms > > And then run this perl script: > >https://gist.github.com/grifferz/1c478ea5eb789b2a1d1a3e49d2a9345c > > The "find" and the "sort" are using NULL-separated strings so that > your filenames can contain newlines. Although I don't expect you > have any such paths under /usr. > > The perl script will print out a chmod for any differences, it will > tell you about paths you have which your "good" host does not, and > it will say nothing about paths that match permissions both sides. > It doesn't actually do anything, it just prints suggested chmod > actions. You maybe want to capture the output to a file. Yes, comparing it to a known good install was something I contemplated but I wasn’t relishing the thought of actually doing it. This will definitely help ease the pain. Thanks! > > If you don't have another working system, well, perhaps you can tell > us which Debian release this is and someone can provide a list of > paths and permissions from their machine. > > Good luck! > > Cheers, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting >
Re: Restoring sticky bits after accidentally moving /usr directory
Hello, On Tue, May 18, 2021 at 06:26:18PM -0400, Steve Dondley wrote: > I goofed up and accidentally moved my /usr directory while trying to make > room on a full drive. I was able to recover, but I'm finding that services > are not working because the sticky bits for many files /usr/bin/* were lost. > For example, I can't send email with exim because of this error: > > Failed to create spool file /var/spool/exim4//input//1lj87g-0002tS-5J-D: > Permission denied I'm guessing you actually mean setuid/setgid bit, not sticky bit. > Is there an easy way to ensure I set all the permissions back to where they > were before I move /usr? I can't think of an easy way if you don't have backups. If you have another system you could get a list of all its permissions like so: # find /usr -xdev -printf '%p %m\0' | sort -z > good-perms Then on your suspect machine: # find /usr -xdev -printf '%p %m\0' | sort -z > suspect-perms And then run this perl script: https://gist.github.com/grifferz/1c478ea5eb789b2a1d1a3e49d2a9345c The "find" and the "sort" are using NULL-separated strings so that your filenames can contain newlines. Although I don't expect you have any such paths under /usr. The perl script will print out a chmod for any differences, it will tell you about paths you have which your "good" host does not, and it will say nothing about paths that match permissions both sides. It doesn't actually do anything, it just prints suggested chmod actions. You maybe want to capture the output to a file. If you don't have another working system, well, perhaps you can tell us which Debian release this is and someone can provide a list of paths and permissions from their machine. Good luck! Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
