Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Negatives to Ignore Timestamp, File Size, etc. #310

Open
pdarragh opened this issue Dec 18, 2008 · 4 comments
Open

Allow Negatives to Ignore Timestamp, File Size, etc. #310

pdarragh opened this issue Dec 18, 2008 · 4 comments

Comments

@pdarragh
Copy link
Contributor

It would be useful to allow negatives to handle cases where only some of the file’s data is useful. For instance, if the timestamp on /foo is unimportant, but the checksum and permissions are important, replacing the timestamp with a dash like this:

f ./foo 0644 0 80 – 143 Bdp3AU5vhGF5kiNgj/s691L4ES4=

would result in the timestamp not being checked.

Original comment by: slaunchaman

@pdarragh
Copy link
Contributor Author

This is a duplicate of 1819368, but the requester never responded to our questions.

Original comment by: fitterhappier

@pdarragh
Copy link
Contributor Author

I’ll respond to the question here since that one appears to be closed. I think a command-line flag to ignore timestamps if the file’s size and checksum match the known value would be acceptable. At the same time, I think allowing it to be specified on a per-file basis would be a better solution. For instance, if you have a program that needs to have the setguid flag set, you could do this:

f ./foo 0644 0 – …

and have fsdiff not check the GID.

Original comment by: slaunchaman

@pdarragh
Copy link
Contributor Author

pdarragh commented Apr 5, 2010

This idea recently resurfaced here as well. We've bumped into some issues where sloppy software allows a group to change in irrelevant manners, requiring radmind runs that do nothing but change the gid on a file permitted 700.

There's definitely a small but real need to ignore some but not all metadata about a given file. We've bumped into cases where badly implemented utilities change the gid of a file to the last writer, as an example. So long as the file is permitted 700, then we don't care what the group is. 1819368 gives an example of this with dates.

Consider also the case of the locate command. To use it, regular runs of 'updatedb' are required. This updates an index file 'locatedb' in a directory, usually '/var/locate'. The directory should not contain anything except that one file, but the file changes in size, date and checksum every night. A negative transcript on the directory causes it to ignore any extra files in that dir, which is not what you want. A negative transcript on the file causes it to be created if it doesn't exist - and that either breaks the locate command (empty file == bad) or makes you create and load a fake db, which then gives misleading results for locate. And while updatedb is running, there will be a 'locate.n' file in the directory. You want to allow such files if they exist, but not create them if they don't. The right way to do this is with a positive transcript that makes existence optional, but if it exists sets proper ownership and permissions while ignoring date and sum.

As a matter of personal importance, ignoring non-existent files is lowest on my priority list. I can always make sure that updatedb is scheduled such that it's done by the time 'ra.sh trip' is started. Date and sum are very high on my list, group in the middle.

In 1819368, wes suggested a command-line option to do this. It's not clear to me how one could do that with, say, 'ra.sh update' and not wind up getting all the dates ignored. Nor does it handle gids, etc.

Original comment by: scsimmons

@pdarragh
Copy link
Contributor Author

I have mixed feelings about "ignore group" (mostly I'm curious how we would specify it in the transcript - an X or * for gid?). I'm not opposed to it, but in my environment I consider UID/GID/Perms to be security-critical (even if their change is effectively a no-op). I want to know if they changed & forcibly reset them when I do a push.


Specifically Re: locatedb and problems along that line, my solution here is a "defaults" transcript (a negative transcript where the files aren't zero-size) -- This lets me push out a mostly-correct locatedb, but doesn't stomp on the ones that get created by the updatedb job in cron.

That solution isn't ideal (IIRC it resets the date), but I think the more generic "don't care about timestamps" patch to fsdiff solves that (though I'm biased in that I don't care about dates so much if my checksums match -- If you care about dates that's not a good solution).

Original comment by: voretaq7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant