HOWTO mass fix FileOwnerShip in case of problem - Redhat

This is a discussion on HOWTO mass fix FileOwnerShip in case of problem - Redhat ; Dear All A Sample Scenario: Assume there is a case which somebody not specificaly you, I mean your collegues, enters sth like this as root, "chown someuser.users .*" and expects to change dot started files, ".bashrc" or ".forward", in a ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: HOWTO mass fix FileOwnerShip in case of problem

  1. HOWTO mass fix FileOwnerShip in case of problem

    Dear All

    A Sample Scenario:
    Assume there is a case which somebody not specificaly you, I mean
    your collegues, enters sth like this as root,
    "chown someuser.users .*" and expects to change dot started files,
    ".bashrc" or ".forward", in a user's home. I would think he was so
    busy and did not think about dot and double-dot represetatives of
    current directory and parent directory. BTW, such thing could result
    SYSTEM WIDE fileownership change....

    And the question:
    At first:
    I moslty want to know your oppinion on HOWTO rollback/fix/recover
    such things, in case of such problem, considering the worst case, e.g.
    I would not roll restore from backup.

    and the second:
    I want to know if you have policies that you are using or think
    is good to use, that could prevent such things?!

    Thanks in advance,
    Looking forward to your responses


  2. Re: HOWTO mass fix FileOwnerShip in case of problem

    Correct the scenario to have "chown -R someuser.users .*", notice the
    "-R" for changing ownership recursivly


  3. Re: HOWTO mass fix FileOwnerShip in case of problem

    On Mar 8, 12:12 pm, "msarm...@gmail.com" wrote:
    > Correct the scenario to have "chown -R someuser.users .*", notice the
    > "-R" for changing ownership recursivly


    chown -R someuser:users .* will change the permissions on the
    "." (current dir) and ".." ( parent dir) and thereby everything under
    the parent dir as well. One possible solution is to script it in such
    a way that you only change the file perms of the dotfiles and not
    anything else. I dont think any policies can stop somebody from having
    a bad day


    Fixing or rolling back such kind of mistakes is usually painful, as
    you absolutely will have to know who owned what before your change..If
    it's a fairly smaller directory, I'd have it restored from backups to /
    tmp or something and look at the perms and script something so that
    the permissions are corrected.


  4. Re: HOWTO mass fix FileOwnerShip in case of problem

    On Thu, 08 Mar 2007 00:11:09 -0800, msarmadi@gmail.com wrote:

    > Dear All
    >
    > A Sample Scenario:
    > ...
    >
    > And the question:
    > At first:
    > I moslty want to know your oppinion on HOWTO rollback/fix/recover
    > such things, in case of such problem, considering the worst case, e.g. I
    > would not roll restore from backup.


    If you're using a journaled file system, then pull the logs. Otherwise,
    you may be stuck with going to a backup and parsing the owners of those
    files from that.
    >
    > and the second:
    > I want to know if you have policies that you are using or think
    > is good to use, that could prevent such things?!


    Clue-by-fours and or flame throwers are a favored technique.

    In more practical terms, maybe restrict who can call chown su[do] root or
    who can even find that executable.

    Luck

  5. Re: HOWTO mass fix FileOwnerShip in case of problem

    msarmadi@gmail.com wrote:
    > Dear All
    >
    > A Sample Scenario:
    > Assume there is a case which somebody not specificaly you, I mean
    > your collegues, enters sth like this as root,
    > "chown someuser.users .*" and expects to change dot started files,
    > ".bashrc" or ".forward", in a user's home. I would think he was so
    > busy and did not think about dot and double-dot represetatives of
    > current directory and parent directory. BTW, such thing could result
    > SYSTEM WIDE fileownership change....
    >
    > And the question:
    > At first:
    > I moslty want to know your oppinion on HOWTO rollback/fix/recover
    > such things, in case of such problem, considering the worst case, e.g.
    > I would not roll restore from backup.
    >
    > and the second:
    > I want to know if you have policies that you are using or think
    > is good to use, that could prevent such things?!


    Not clear what you are trying to get back to from the example but -R works fine.

    chown -R joe.blow

    --
    There is no excuse for us to accept from politicians anything that we would
    never accept from our own children. Maybe that is why they work at appearing
    lovable.
    -- The Iron Webmaster, 3723
    nizkor http://www.giwersworld.org/nizkook/nizkook.phtml
    Mission Accomplished http://www.giwersworld.org/opinion/mission.phtml a12

  6. Re: HOWTO mass fix FileOwnerShip in case of problem

    On Mar 9, 1:35 am, "Kalyan Manchikanti"
    wrote:
    > On Mar 8, 12:12 pm, "msarm...@gmail.com" wrote:
    >
    > > Correct the scenario to have "chown -R someuser.users .*", notice the
    > > "-R" for changing ownership recursivly

    >
    > chown -R someuser:users .* will change the permissions on the
    > "." (current dir) and ".." ( parent dir) and thereby everything under
    > the parent dir as well. One possible solution is to script it in such
    > a way that you only change the file perms of the dotfiles and not
    > anything else. I dont think any policies can stop somebody from having
    > a bad day
    >
    > Fixing or rolling back such kind of mistakes is usually painful, as
    > you absolutely will have to know who owned what before your change..If
    > it's a fairly smaller directory, I'd have it restored from backups to /
    > tmp or something and look at the perms and script something so that
    > the permissions are corrected.


    Thanks
    I guess this solution is the most practical and less painfull one for
    me.


  7. Re: HOWTO mass fix FileOwnerShip in case of problem

    On 11 Mar 2007, in the Usenet newsgroup linux.redhat, in article
    <1173680144.452202.244840@30g2000cwc.googlegroups.c om>, msarmadi@gmail.com
    wrote:

    >On Mar 9, 1:35 am, "Kalyan Manchikanti"
    >wrote:


    >> Fixing or rolling back such kind of mistakes is usually painful, as
    >> you absolutely will have to know who owned what before your change..If
    >> it's a fairly smaller directory, I'd have it restored from backups to /
    >> tmp or something and look at the perms and script something so that
    >> the permissions are corrected.

    >
    >Thanks
    > I guess this solution is the most practical and less painfull one for
    >me.


    For _system_ files - which really means those that were installed by
    the 'rpm' package manager

    [compton ~]$ rpm --help | grep -A2 -- -set
    --setperms - set the file permissions to those in the package
    database using the same package specification
    options as -q
    --setugids - set the file owner and group to those in the
    package database using the same package
    specification options as -q
    [compton ~]$

    but this won't do anything for stuff in /home/ or similar files that are
    not installed by rpm. Of course, the universal solution is to restore
    everything from backups - you do have those, right? ;-)

    Old guy

  8. Re: HOWTO mass fix FileOwnerShip in case of problem

    On Mar 12, 10:56 pm, ibupro...@painkiller.example.tld (Moe Trin)
    wrote:
    > On 11 Mar 2007, in the Usenet newsgroup linux.redhat, in article
    > <1173680144.452202.244...@30g2000cwc.googlegroups.c om>, msarm...@gmail.com
    > wrote:
    >
    > >On Mar 9, 1:35 am, "Kalyan Manchikanti"
    > >wrote:
    > >> Fixing or rolling back such kind of mistakes is usually painful, as
    > >> you absolutely will have to know who owned what before your change..If
    > >> it's a fairly smaller directory, I'd have it restored from backups to /
    > >> tmp or something and look at the perms and script something so that
    > >> the permissions are corrected.

    >
    > >Thanks
    > > I guess this solution is the most practical and less painfull one for
    > >me.

    >
    > For _system_ files - which really means those that were installed by
    > the 'rpm' package manager
    >
    > [compton ~]$ rpm --help | grep -A2 -- -set
    > --setperms - set the file permissions to those in the package
    > database using the same package specification
    > options as -q
    > --setugids - set the file owner and group to those in the
    > package database using the same package
    > specification options as -q
    > [compton ~]$
    >
    > but this won't do anything for stuff in /home/ or similar files that are
    > not installed by rpm. Of course, the universal solution is to restore
    > everything from backups - you do have those, right? ;-)
    >
    > Old guy


    Thank you old guy, that was really helpfull
    Actually, I don't have any backup though. But I'll do it for sure,
    after getting everything fixed.


  9. Re: HOWTO mass fix FileOwnerShip in case of problem

    On 22 Mar 2007, in the Usenet newsgroup linux.redhat, in article
    <1174563437.757885.24620@p15g2000hsd.googlegroups.c om>, msarmadi@gmail.com
    wrote:

    >Actually, I don't have any backup though. But I'll do it for sure,
    >after getting everything fixed.


    When you see how much time and effort you've wasted without them, it
    gives you the incentive to do _something_ to avoid the problem in the
    future. It might be as simple as getting a second computer and
    networking the two so you can copy critical files. It doesn't need to
    be something new - doesn't even need a monitor and keyboard.

    Old guy

+ Reply to Thread