Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #235337 > unrolled thread

Restoring sticky bits after accidentally moving /usr directory

Back to article view | Back to linux.debian.user

Contents

  Restoring sticky bits after accidentally moving /usr directory Steve Dondley <s@dondley.com> - 2021-05-19 00:30 +0200
    Re: Restoring sticky bits after accidentally moving /usr directory Andy Smith <andy@strugglers.net> - 2021-05-19 01:50 +0200
      Re: Restoring sticky bits after accidentally moving /usr directory s@dondley.com - 2021-05-19 02:10 +0200
      Re: Restoring sticky bits after accidentally moving /usr directory Greg Wooledge <greg@wooledge.org> - 2021-05-19 05:50 +0200
        Re: Restoring sticky bits after accidentally moving /usr directory Andy Smith <andy@strugglers.net> - 2021-05-19 13:00 +0200
    Re: Restoring sticky bits after accidentally moving /usr directory David <bouncingcats@gmail.com> - 2021-05-19 02:20 +0200
    Re: Restoring sticky bits after accidentally moving /usr directory songbird <songbird@anthive.com> - 2021-05-19 02:30 +0200
      Re: Restoring sticky bits after accidentally moving /usr directory Tixy <tixy@yxit.co.uk> - 2021-05-19 08:50 +0200
        Re: Restoring sticky bits after accidentally moving /usr directory Tixy <tixy@yxit.co.uk> - 2021-05-19 09:00 +0200
    Re: Restoring sticky bits after accidentally moving /usr directory Andrei POPESCU <andreimpopescu@gmail.com> - 2021-05-19 09:30 +0200
    Re: Restoring sticky bits after accidentally moving /usr directory Hans <hans.ullrich@loop.de> - 2021-05-19 12:40 +0200
      Re: Restoring sticky bits after accidentally moving /usr directory Steve Dondley <s@dondley.com> - 2021-05-19 19:20 +0200
        Re: Restoring sticky bits after accidentally moving /usr directory songbird <songbird@anthive.com> - 2021-05-19 20:00 +0200

#235337 — Restoring sticky bits after accidentally moving /usr directory

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?

[toc] | [next] | [standalone]

#235341

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

[toc] | [prev] | [next] | [standalone]

#235343

[Multipart message — attachments visible in raw view] — view raw

>> 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
> 

[toc] | [prev] | [next] | [standalone]

#235352

On Tue, May 18, 2021 at 11:46:38PM +0000, 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.

[toc] | [prev] | [next] | [standalone]

#235366

Hello,

On Tue, May 18, 2021 at 11:40:38PM -0400, Greg Wooledge wrote:
> On Tue, May 18, 2021 at 11:46:38PM +0000, 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

[toc] | [prev] | [next] | [standalone]

#235344

On Wed, 19 May 2021 at 08:26, Steve Dondley <s@dondley.com> 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.

[toc] | [prev] | [next] | [standalone]

#235346

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

[toc] | [prev] | [next] | [standalone]

#235355

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

[toc] | [prev] | [next] | [standalone]

#235356

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

[toc] | [prev] | [next] | [standalone]

#235358

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#235365

[Multipart message — attachments visible in raw view] — view raw

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?

[toc] | [prev] | [next] | [standalone]

#235387

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.

[toc] | [prev] | [next] | [standalone]

#235398

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web