| Summary: | Setup or shadow-utils package should provide /etc/subuid and /etc/subgid | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Daniel Walsh <dwalsh> | |
| Component: | setup | Assignee: | Ondrej Vasik <ovasik> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 24 | CC: | amurdaca, dennis, dwalsh, ebiederm, mattdm, mitr, ovasik, pknirsch, pvrabec, tmraz | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | setup-2.10.1-1.fc23 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1311278 (view as bug list) | Environment: | ||
| Last Closed: | 2016-02-29 05:24:33 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Bug Depends On: | ||||
| Bug Blocks: | 1311278 | |||
|
Description
Daniel Walsh
2016-02-17 18:54:37 UTC
I notice that the man pages for these files are in shadow-utils.... but then, that's also true for several other files owned by "setup". I guess I don't have a strong opinion either. :) As the other mapping files are in setup, I'd say that these two files should be there as well for consistency. I'd add them to shadow-utils only in case there is some particular reason why they should not be in setup. I agree with setup ownership here, as it already owns the other mapping files as Tomas mentioned. What content is expected in these files? Should they be just empty or should they contain some basic content? No idea, I guess we can steal what ubuntu has done. Eric do you have any opinion on the content? $ cat /etc/subuid # empty default subuid/subgid file $ cat /etc/subgid # empty default subuid/subgid file That's probably the default content there. I'll use it as well if nobody objects. Yes empty files will work just fine (docker will write to then when needed) Built as setup-2.10.1-1.fc24 ... do you need that for F22/F23 as well ? I would say this is needed for f23 and rhel7 only. We don't plan on updating to docker-1.10 in f22 or in rhel6. setup-2.10.1-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-7d3f9038c7 This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase setup-2.10.1-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-7d3f9038c7 I expected those files to be empty on a fresh rawhide install, instead I get:
[root@2-rawhide-userns ~]# cat /etc/sub{uid,gid}
# empty default subuid/subgid file
tss:100000:65536
# empty default subuid/subgid file
tss:100000:65536
There are also "dash-postfixed" files there:
[root@2-rawhide-userns ~]# ll /etc/sub*
-rw-r--r--. 1 root root 52 Feb 26 06:57 /etc/subgid
-rw-r--r--. 1 root root 35 Feb 22 09:11 /etc/subgid-
-rw-r--r--. 1 root root 52 Feb 26 06:57 /etc/subuid
-rw-r--r--. 1 root root 35 Feb 22 09:11 /etc/subuid-
[root@2-rawhide-userns ~]# cat /etc/sub{uid,gid}-
# empty default subuid/subgid file
# empty default subuid/subgid file
I don't have any clue about who's adding those there but nvm.
[root@2-rawhide-userns ~]# rpm -qf /etc/subuid
setup-2.10.1-1.fc24.noarch
[root@2-rawhide-userns ~]# rpm -qf /etc/subgid
setup-2.10.1-1.fc24.noarch
[root@2-rawhide-userns ~]# rpm -qf /etc/subgid-
file /etc/subgid- is not owned by any package
[root@2-rawhide-userns ~]# rpm -qf /etc/subuid-
file /etc/subuid- is not owned by any package
Also docker installation is adding dockerroot user (which is totally wrong afaict and conflicts with docker userns implementation, I've removed its creation from docker dist-git):
[root@2-rawhide-userns ~]# cat /etc/sub{uid,gid}
tss:100000:65536
# empty default subuid/subgid file
dockerroot:165536:65536
tss:100000:65536
# empty default subuid/subgid file
dockerroot:165536:65536
[root@2-rawhide-userns ~]# cat /etc/sub{uid,gid}-
# empty default subuid/subgid file
tss:100000:65536
# empty default subuid/subgid file
tss:100000:65536
Also note docker startup fails because it's incorrectly parsing the comment line as a valid line - I can create a PR upstream but is it correct to have comments in those files? if yes, I'll update docker - otherwise we should remove the commented line.
alright, I've noticed files such as /etc/passwd ignore commented out lines - I'll go ahead and fix docker to ignore them as well (In reply to Antonio Murdaca from comment #15) > alright, I've noticed files such as /etc/passwd ignore commented out lines - > I'll go ahead and fix docker to ignore them as well No, there is no documented comment format in /etc/passwd. #-starting lines in /etc/passwd is just creating users with name '# Hello this is a comment', or perhaps such lines are being silently ignored as malformed because they lack mandatory fields like an UID. If the official documentation of /etc/subuid is shadow-utils’ subuid(5) (is it?), that does not mention any comments, so none are supported. In that case we should not be shipping any nor patching other software to treat #-starting lines in such non-standard ways. Ack, thanks Miloslav. We should remove the comment from those files then. setup-2.10.1-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. This comment was added based on the https://github.com/lxc/lxd/issues/314 ... where ubuntu uses exactly same comment there... They either removed it later or have docker "broken" the same way. I'm fine with removal of these lines, though... intention was to keep the files same as (probably) on Ubuntu - based on the comments in this github issue. Sounds like removing the lines is the safest thing to do. |