Default file/folder permissions under '/etc' = ?
Hi, I have a friend I pushed very hard to move to Linux and now made for himself (and also for me) an extremely unpleasant situation:( Before I would attempt to fix really _all_ the file/folder permissions he ruined in '/etc' on his SUSE 9.1, would like to ask your opinion please, what I could do. As I understood, he did somehow a recursive chown and changed ALL of the stuff in the above folder to have the owner root:root :((( I wouldn't like to "lose him" and let him return so easily to the dark side! So at first I let SuSEconfig fix the most important stuff on that comp. At second I have all of the official .html pages from the Novell's site concerning 9.1, where all of their .rpm packages are listed with files/folders AND access rights detailed. I filtered out from them all of the lines having '/etc' in their pathnames and having NO root:root as owner. That was a not so huge list and changed 'back' all of that stuff, causing the system working now without Mb-s of bloody error-logs. Is there please a more precise way to get rid of this access-right problem? Would e.g. changing the system's general security-level to a very high level then back help us/me? I have physical access to that system. Thanks, Pelibali
Fri, 17 Jun 2005, by pelibali@freemail.hu:
Hi,
I have a friend I pushed very hard to move to Linux and now made for himself (and also for me) an extremely unpleasant situation:( Before I would attempt to fix really _all_ the file/folder permissions he ruined in '/etc' on his SUSE 9.1, would like to ask your opinion please, what I could do. As I understood, he did somehow a recursive chown and changed ALL of the stuff in the above folder to have the owner root:root :(((
[..]
Is there please a more precise way to get rid of this access-right problem? Would e.g. changing the system's general security-level to a very high level then back help us/me? I have physical access to that system.
rpm -qf `rpm -qal|grep /etc`|sort -u > setugids.txt This gives a sorted list of packages with files in /etc With rpm --setugids you can reset the UId and GID to the rightfull names, so feed this command with the list you just generated. # rpm --setugids $(cat setugids.txt) HTH Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 9.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.8 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply.
Hi, On Fri, 17 Jun 2005 21:36:43 +0200 "Theo v. Werkhoven" <.> wrote: <...>
rpm -qf `rpm -qal|grep /etc`|sort -u > setugids.txt This gives a sorted list of packages with files in /etc
With rpm --setugids you can reset the UId and GID to the rightfull names, so feed this command with the list you just generated. # rpm --setugids $(cat setugids.txt)
Thank you, it worked just perfectly! I even archived your mail for further studying. In fact I'm sure, that we will reinstall that particular comp, but it will not happen in weeks/months, because seemingly we could get it work now (=no MBs of error-logs). Actually last time I was quite effective while using my own "dummy" strategy to fix the file/folder rights, because there was only a single group corrected by your method: I did chown lp:lp and not lp:sys once... In the same time Randall is completely right with the number of files located under /etc and many of them really don't come directly from RPMs, are links or whatever. My friend is happy now to get back his system and he (+we) learned again something on the importance of regular and complete backups. He most likely stays with Linux and understood that this incident was not caused e.g. by a drunken penguin, but was his own fault... Thanks for all of you replying this topic, Pelibali
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2005-06-17 at 18:39 +0200, pelibali wrote:
side! So at first I let SuSEconfig fix the most important stuff on that comp. At second I have all of the official .html pages from the Novell's site concerning 9.1, where all of their .rpm packages are listed with files/folders AND access rights detailed. I filtered out from them all of the lines having '/etc' in their pathnames and having NO root:root as owner. That was a not so huge list and changed 'back' all of that stuff, causing the system working now without Mb-s of bloody error-logs.
Ouch. You could get the list of files out of the command pin, perhaps... also, with rpm databases it is possible to detect which files have changed. I'm not sure if it can list the original permissions, I'd have to study it.
Is there please a more precise way to get rid of this access-right problem? Would e.g. changing the system's general security-level to a very high level then back help us/me? I have physical access to that system.
Don't think so... root can always mess it. The only way would be to keep the root password out of his hands, or at worst, inside a sealed envelope. If you find the seal broken, you spank him ;-) - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCsyodtTMYHG2NR9URAnRZAKCYdxAX5Z3/4Z/oOxCBj6MJEOwZZwCdGgyi OcvT8lmb1x3DMQ2v0U5Hngw= =4nWW -----END PGP SIGNATURE-----
Pelibali, On Friday 17 June 2005 09:39, pelibali wrote:
Hi,
I have a friend I pushed very hard to move to Linux and now made for himself (and also for me) an extremely unpleasant situation:( ...
I wouldn't like to "lose him" and let him return so easily to the dark side!
Theo W.'s solution is quite elegant, though it will fix only files that derived directly from RPMs. Oddly enough, on my system, there are many more (1739) files and directories in the list produced by the command rpm -qal |grep /etc |sort -u than there are files or directories in my /etc. There are also a few entries in that list that do not exist in my /etc hierarchy. Offhand, I cannot explain these discrepancies, but I haven't tried hard to do so. Naturally, there are quite a few files in /etc that do not derive directly form any RPM and they won't be fixed by Theo's technique. To know which they are, you can diff the output of the command above with that of "find /etc |sort". Please make sure your friend understands that there is a direct counterpart to his blunder in Windows, and that this incident should not drive him away from Linux.
...
Thanks, Pelibali
Randall Schulz
participants (4)
-
Carlos E. R. -
pelibali -
Randall R Schulz -
Theo v. Werkhoven