Write permissions ignored [SOLVED]

[jpeps]

This might be the key to protecting the cups permissions. I tried this, and the printer still works. For adding new printers, it could be reversed with chattr -i

(note: problems typically occur when root:nobody gets overwritten to root:root)

Code: Select all

#!/bin/sh

[ -f /tmp/list ] &&  rm /tmp/list
cd /etc/cups
ls -l | grep "nobody" | cut -d " " -f8 >>/tmp/list

cd /initrd/pup_rw/etc/cups

while read line; do
    chattr +i "$line"
done < /tmp/list

 chattr -R +i /initrd/pup_rw/var/cache/cups
 chattr -R +i  /initrd/pup_rw/var/log/cups
  
rm /tmp/list

[thunor]

If thunor is still reading, the complaint is solved. Well, thunor what will it
be?

Ok, I'm back

So, I can go through /initrd/pup_rw/root and use chattr +i and chattr -i to prevent files from being deleted, or wrap a game in a script to remove/replace its rcfile.

Interestingly I appear to have killed two birds with one stone because rkhunter (which I recently downloaded and installed) does a lsattr test which fails, dumping the same ioctl error messages as reported earlier. I couldn't find anything about this problem so currently the test is being skipped.

Thanks for the assistance. I've marked this as solved.

[Bruce B]

Interestingly I appear to have killed two birds with one stone.

If I knew we wanted to kill birds, I'd have brought up the subject of
shotguns and bird shot.

In South Carolina or Utah, they think something is wrong with you if you
don't have a shotgun. I like two barrels, one with a slug and the other
with shot. Who knows what kind of varmint we will run into?

In the Republic of California, they don't want you to have shotguns. They
don't even want Charlie Sheen to have any kind of gun. But he can have
all the sluts he wants. That's legal I guess, just don't shoot birds in the
City Limits of Los Angeles.

As for credit, I think disciple gets it for figuring out where to run the
command.

You could move chattr and lsattr to different names.

~

[Shep]

How to make a file immutable. Root cannot modify it or even delete it.
Except with chattr to put attributes back.

Code block demonstrates

Code: Select all

[/mnt/sda2/lupu] chattr +i isolinux.cfg
[/mnt/sda2/lupu] lsattr
-------------- ./lupu-520.iso.md5
----i--------- ./isolinux.cfg
-------------- ./lupu-520.iso
-------------- ./boot.msg
-------------- ./help.msg
-------------- ./help2.msg
[/mnt/sda2/lupu] rm isolinux.cfg
rm: remove write-protected regular file `isolinux.cfg'? y
rm: cannot remove `isolinux.cfg': Operation not permitted
[/mnt/sda2/lupu]

~

How interesting! Where did you find out about this command? Where have you ever had a need to use it?

Anyway, works for me. I have no idea, now, how my file system is ext3. I guess it must default to ext3?

/dev/sda6 on /mnt/sda6 type ext3 (rw,relatime,errors=continue,data=writeback)

[Bruce B]

How interesting! Where did you find out about this command? Where have you ever had a need to use it?

Just using Linux for about a decade.

Frequently, I read mosts from people complaining "Puppy didn't save my
[configuration] settings."

I've never responded to one of these posts. The reason why is; the
premise may be faulty.

They think Puppy didn't save the settings because when Puppy rebooted,
the saved settings were not there.

In order to determine if Puppy 'saved' the settings, the user would have
to check for changes BEFORE rebooting. I've never seen a user with the
complaint do this.

Let us consider Puppy is a portable operating system. It does not
presume it is booting on the identical hardware it was last used on.

This is why a person can take a Flash stick and boot it on another
computer.

Puppy probes and configures on each boot.

Back to the user's complaint. If he didn't check to see if the settings were
actually saved, the only thing he knows is; the saved settings were not
available on next boot.

It could very well be the settings were saved and got lost or overwritten
on boot up.

Look at all the arguing I have to do, to get the user to broaden his
premise.

I'm not going to do it. I've never presented this argument before and
don't plan to do it again.

Where have you ever had a need to use it?

If we work on the premise that Puppy can and sometimes does mess up
our configuration on boot up, we can protect ourselves.

xorg.conf and resolv.conf would be two examples of configuration files to
make immutable. That is, if we are always running on the same hardware.

If you find your volume controls get changed by xyz program, and it
annoys you, then make asound.state immutable

And of course any personal files you don't want to accidentally delete or
lose.

~