Activating SU in a script and not having to enter the password.

[Fragglehaggle]

I'm trying to make it to where I can change the permissions of a file so that anyone can read sed file; however the file is being printed by the root & can only be changed via the root. I created a script but it still needs a password & I would like it to where a password is not required.
My Script

for file in /home/mmkmmk3/history/*.txt
do
chmod 777 $file >> results.out
done

Now is there anyway I can bypass having to enter in any password? I know the risk of an automated root password enter via a script so I don't need a lecture on that, mind you. A nice fix would be nice!

[sicarie]

Not familiar with a way to do that off the top of my head, but a few workarounds might be:

1) Use a cron job under root to run every so often (nightly, hourly, your preferred interval) and reset the permissions in that directory chmod 777 /home/mmkmmk3/history/*.txt

2) use another system with SSH keys set up so there's no authentication, and run it as root from there

and a horribly insecure workaround would be

3) reset root's umask to have ------rwx set This will mean that ANY file created by root will be visible to every user on the system and can easily create vulnerabilities

[Fragglehaggle]

That third one would work, could you explain it some more. I understand the risk but these files are worthless to anyone else.

The first one, I don't know what a cron job is, could you also expand on that. Sorry for being so unfamiliar

[zmbd]

CRON is the scheduled task manager for UNIX based systems:
CRON quick reference
and a much more in-depth tutorial
Linux tip: Job scheduling with cron...

Have you looked at Group settings over a directory.
Linux Files and File Permission (you can find the same information via the IBM link, just click thru) Redirect the output of the file in question to the correct folder and set the group rights:

Directory Set Group ID
If the setgid bit on a directory entry is set, files in that directory will have the group ownership as the directory, instead of than the group of the user that created the file.

This attribute is helpful when several users need access to certain files. If the users work in a directory with the setgid attribute set then any files created in the directory by any of the users will have the permission of the group. For example, the administrator can create a group called spcprj and add the users Kathy and Mark to the group spcprj. The directory spcprjdir can be created with the set GID bit set and Kathy and Mark although in different primary groups can work in the directory and have full access to all files in that directory, but still not be able to access files in each other's primary group.

and a horribly insecure workaround would be

Is an understatement!

IMHO: Fragglehaggle: Stay the [insert foot here] away from that last option. I guarantee that if that file is important to you for anything other than making paper airplanes, someone else will want it too, more importantly is that you open the ROOT to potential hacks - that would have been a dream mask back in the day! };-)

[Fragglehaggle]

It's simply homework for my Linux class. I don't think anyone else wants it, much less would I care if they took it.

Thanks for the link to the cron task. I'll check it out soon!

[zmbd]

Homework is valuable.
To tell my age a tad... 20+ years ago while at university, my CompSci account was hacked and the individual d/l the code, del from my account, and attempted to use my code for his classwork; sucked for him that I'd already compiled and turned the code and program into the prof about an hour before he did... funny, is that he had my Beta Code.
20 years, and when I go to visit, Dr.P and I still get a laugh over a beer - and he's the one telling the story.

Oh, and we cross posted... I add the group/directory level information.

[sicarie]

zmbd - I totally forgot about the sticky bit - great idea!

Fragglehaggle - zmbd is totally right - both other options are so much better than option 3. Re-setting root's umask is something you do on a vm you know you're going to wipe out as soon as you're done working on it - it's really a last-ditch option.

[Fragglehaggle]

These are just simple lab projects that are usually just testing certain commands, and the affects of using different variables & strings. Comm. College. I do want to use a VM it would be nice. I'd rather have it & not need it than need it & not have it.

[sicarie]

Speaking as a teacher of Linux in a community college, I can definitely say learning to work around without the umask will be MUCH more valuable - using the sticky bit, cron, or pre-shared auth.

If you really want to learn umasks, then set the umask for the individual user and validation your permissions, not root.

I think the sticky bit is the best option - learn how to limit permissions - and the cron is the second best - you can set the interval to as low as every minute if you want, so you will just have to wait 60 seconds if your command fails on permissions...

[Fragglehaggle]

I do respect & appreciate all the info, but I'd still rather have it & not need it than otherwise.

[sicarie]

Sure, it would be modifying the umask option in the user's profile file - I believe it's in the octal notation, so 000 through 777 depending on your preferred permissions, the last number being your desired setting (this is assuming that the folder/path has the permissions to allow access as well).