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

Expose issues with file ownership / permissions / attributes (Ideally as part of "Scheduled Validation") #836

Open
marclaporte opened this issue Jun 22, 2024 · 11 comments

Comments

@marclaporte
Copy link
Contributor

2024-06-22_132523

It would be nice to know what it solved. It would be even nicer to have this as part of the scheduled validation. So we could quickly be alerted about issues (Usually, the sooner we know, the easier it is to address the root cause)
2024-06-22_132916

Many times, we have wasted time because someone worked as root and forgot to chown a file, or a script running as root created some files, some files were migrated from another site, and we forgot to change the owner, etc.

I realize it could be super slow to do this. So maybe it should be a check box in scheduled validation "Also validate file permissions".

@iliajie
Copy link
Collaborator

iliajie commented Jun 22, 2024

Hey Marc!

This feature makes sense. However, it would imply that we won't be able to use chown as we do now for this, since it only returns the number of files affected and not the list of files that was affected.

I don't recall at the moment if we also apply chmod, but if not, it could also be optionally added and done based on umask settings.

We will need to wait for Jamie's comment on this.

@jcameron
Copy link
Collaborator

Checking permissions on all the files that Fix Permissions fixes could be really slow, so I don't think we could do this as part of scheduled validation.

@marclaporte
Copy link
Contributor Author

could be really slow, so I don't think we could do this as part of scheduled validation

I understand.

However, it would imply that we won't be able to use chown as we do now for this, since it only returns the number of files affected and not the list of files that was affected.

Even just the number of files affected would be nice because it's a hint of the presence or absence of an issue.

I have an idea: chown [-c|--changes] "displays information about files that are actually changed. For example: changed ownership of 'dir/dir1/file1' from hope:neil to hope:hope"

Source: https://www.computerhope.com/unix/uchown.htm

@iliajie
Copy link
Collaborator

iliajie commented Jun 23, 2024

We use Perl's chown for this purpose. We either need to shell out to use chown with the --changes flag or by stating files like:

my ($orig_uid, $orig_gid) = (stat $file)[4, 5];
if ($orig_uid != $uid || $orig_gid != $gid) {
    if (chown($uid, $gid, $file)) {
        push @changed_files, $file;
        }
    }

@jcameron
Copy link
Collaborator

We could certainly show the list of files that were changed on the Fix Permissions page..

@iliajie
Copy link
Collaborator

iliajie commented Jun 23, 2024

Yeah, I know. But I think we should make a new Virtualmin 7.20.0 release and keep this particular feature for later!

We also need to wrap up Webmin and Usermin next week, as after that I need to finish the WordPress Workbench and start reworking Cloudmin. The time has come!

@marclaporte
Copy link
Contributor Author

Yeah, I know. But I think we should make a new Virtualmin 7.20.0 release and keep this particular feature for later!

Sure, let's keep as a nice-to-have one day. I look forward to 7.20.0!

@iliajie
Copy link
Collaborator

iliajie commented Aug 31, 2024

Can this ticket be closed?

@marclaporte
Copy link
Contributor Author

No yet. We are still missing:

We could certainly show the list of files that were changed on the Fix Permissions page..

@iliajie
Copy link
Collaborator

iliajie commented Aug 31, 2024

No yet. We are still missing:

We could certainly show the list of files that were changed on the Fix Permissions page..

Ah, that's right!

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

No branches or pull requests

3 participants