-
Notifications
You must be signed in to change notification settings - Fork 13
Fix annoying "permission denied" when saving running-config #979
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
Conversation
For future readers, the user paramenter to the copy() function is actually the remote user in any curl command. Also, realign columns in infix_config[]. Signed-off-by: Joachim Wiberg <[email protected]>
When copying a file to a directory, the file should be accessible (read + write) by all members of the group that are allowed write access. E.g., an 'admin' level user creating a new file /cfg/foo.cfg should result in the file being owned by $LOGNAME:wheel with 0660 perms, because /cfg is root:wheel. Writing to already existing file, e.g., created by 'root' at first boot, say /cfg/startup-config.cfg should be possible by all members of the 'wheel' group. In this case thef file already exists as root:wheel and any user trying to chgrp it will fail, this is fine. Fixes #977 Signed-off-by: Joachim Wiberg <[email protected]>
As per earlier decsision, the .cfg suffix is no longer implied when a user copy to a regular file, so we should allow tab completion in the copy command to show foo.cfg, otherwise the copy command will fail. Skip /cfg/startup-config.cfg since it's treated as a special case and added to the list by the infix_datastore() plugin function. Signed-off-by: Joachim Wiberg <[email protected]>
Signed-off-by: Joachim Wiberg <[email protected]>
Signed-off-by: Joachim Wiberg <[email protected]>
* E.g., writing to /cfg/foo, where /cfg is owned by root:wheel, | ||
* should result in the file being owned by $LOGNAME:wheel with | ||
* 0660 perms for other users in same group. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we made sure that we create startup
with g+s
, could we rely on the kernel to handle this logic for us?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we made sure that we create
startup
withg+s
, could we rely on the kernel to handle this logic for us?
You mean on /cfg
, I assume. Yes, but I was worrying about bind + overlay mounts, as well as external media with vfat/exfat file systems.
return 0; | ||
} | ||
|
||
getgrouplist(user, pw->pw_gid, groups, &num); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't there's a theoretical race here, if the user is added to a group after the last call to getgrouplist()? If so, perhaps it's worth wrapping this in an if (..... != -1).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is, wrapping it with a realloc()
is probably a good idea to be safer.
src/bin/copy.c
Outdated
return 0; | ||
|
||
strlcpy(dir, fn, sizeof(dir)); | ||
ptr = strrchr(dir, '/'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this block use dirname()
to make it easier to understand?
CCB: assigning to @rical to fix the comments. Thanks! |
Avoid a theoretical race between getting the number of groups a user belongs to and actually processing them. We should not need to check the return value of getgrouplist() as we know the number of groups fit inside the buffer. Signed-off-by: Richard Alpe <[email protected]>
Cosmetic change intended to improve code readability. Signed-off-by: Richard Alpe <[email protected]>
Prior to this patch the errno value was overwritten by getgrgid() making the printouts invalid: Error: setting group owner wheel (10) on /cfg/startup-config.cfg: Success Signed-off-by: Richard Alpe <[email protected]>
Signed-off-by: Richard Alpe <[email protected]>
The code assumes both SRC and DST is passed, here we ensure this early. Prior to this patch: root@host:~$ copy foo Segmentation fault (core dumped) Signed-off-by: Richard Alpe <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work, looks good to me!
Unfortunately our policies prevent me from approving my own PR, so maybe @jovatn can make the formal approval?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comment
Signed-off-by: Richard Alpe <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Description
Fixes #977
Checklist
Tick relevant boxes, this PR is-a or has-a: