You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Creating a new file or directory when logged in with a normal user, but having elevated permissions (Administrative access) will create files owned by root:root instead of the current user.
To Reproduce
Steps to reproduce the behavior:
Click on 'New file' or 'New director' icon buttons in the UI and create that
See file ownership bring root:root
Expected behavior
currentuser:currentuser permissions are expected, even when logged in with 'Administrative access'
Screenshots
The text was updated successfully, but these errors were encountered:
I think the problem is that when we spawn the touch.py3 process using cockpit.spawn() we pass "superuser": "try", which tries to run the process as root (which I think it succeeds to do since the user has administrative access, not sure). When a user creates a file as root, the owner of the file will be root:root.
As an user, I have experienced this many times in Linux, where I expect my user account to be the owner when creating a file as root, however I got used to root being the owner then changing permissions as required over time,
Some might prefer the ability to modify filesystems with 'superuser',
Many will have Administrative access active and still expect the filesystem modifications be done without 'superuser'.
If we use a toggle at the top bar of file manager page to edit files as "superuser" / "regular user", defaulting to "regular user", this enables a quick way to switch to and back from 'administrator mode' just for the file manager page.
Bug Info
Creating a new file or directory when logged in with a normal user, but having elevated permissions (Administrative access) will create files owned by root:root instead of the current user.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
currentuser:currentuser permissions are expected, even when logged in with 'Administrative access'
Screenshots
The text was updated successfully, but these errors were encountered: