Bug 1192088
| Summary: | Reserve static gid/uid for jboss user | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Marek Goldmann <mgoldman> |
| Component: | distribution | Assignee: | David Walluck <dwalluck> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Katerina Odabasi <kanovotn> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 6.4.0 | CC: | cdewolf, dpal, dwalluck, fnasser, jdoyle, mgoldman, myarboro, ovasik, pgier, pslavice, vtunka |
| Target Milestone: | CR1 | ||
| Target Release: | EAP 6.4.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-06-08 08:03:02 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: | |
| Embargoed: | |||
| Bug Depends On: | 1192412, 1192413 | ||
| Bug Blocks: | |||
In Fedora a static uid/gid 185 was registered for JBoss AS and later reused by WildFly: https://git.fedorahosted.org/cgit/setup.git/tree/uidgid?id=fb80b722656989461f8a8d5001d22a05abe28890#n151 I presume the current behavior is the behavior of 6.3 when installed via RPMs? What's the effect for someone upgrading if we make this change? From what I know there is no change, since the user ID's are assigned only when the RPM is installed for the first time. For upgrades - the already existing ID's will be reused. Ondrej, could you please confirm that ID 185 is registered for 'jboss-as' user in the setup package? I have two questions around this: 1. Is it save to use uid/gid for all supported RHEL versions now (5, 6, 7)? 2. Is there a chance the 'jboss-as' user could be renamed to 'jboss' so it could match the EAP user? RHEL 5 definitely not - threshold for static allocations is just 100 (and there are no free uidgid pairs under threshold). RHEL 6 and RHEL 7 contain jboss-as reservation, if you want to update them, please file bugzillas against them. In addition, actually current Fedora Rawhide has following entry for "former jboss-as" - as rename to wildfly was requested by https://bugzilla.redhat.com/show_bug.cgi?id=995045#c4 : wildfly 185 185 /usr/share/wildfly /sbin/nologin wildfly #was jboss-as So yes, rename in registration for successor is possible - it is just guidance reservation file, it will just make the comment even more confusing - as I would have to mention wildfly as well to prevent confusion. Please use soft-static allocation approach ( https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allocation ) when using the static reserved id - and you should probably be safe even on RHEL 5 - worst case you can get is dynamic system id, if the 185 is already occupied. Ondrej, thanks for the update. We are not interested in RHEL5 much - given we can't change it anymore. This is for John to ACK. I will file a BZ against RHEL6 and RHEL7. We will triage this BZ today, so hopefully this gets to RHEL PM as well. Created two blocker BZs for RHEL6 & RHEL7 and set appropriate flags reflecting severity of this for layered products. Acking per dicsussion with Kabir on blocker triage. Adding pmuir to CC per discussion with Marek, so devexp team is aware. ack'd I've informed the RHEL PM, is there anything remaining to be done on this issue? Can someone please link the BZ# for the RHEL-6 and 7 number allocations? John, that's all, thank you very much. Fernando, the RHEL BZs are linked in "depends on": BZ1192412, BZ1192413. I assigned this BZ to you, it that OK? Fedora/Rawhide has wildfly RHEL has jboss-as Now the proposal is to rename it to 'jboss' in an undetermined timeframe. OK, so now we have a static user with predefined UID/GID. This is fine however would be nice to understand the following: - Can this user be managed remotely (some people put users like this into central LDAP and manage them centrally). In this case we need to understand whether it is a preferred or recommended option - What is a group membership of this user? Can he be a member of the central or local groups? - What are other policies around this user? SELinux, sudo, host based access control? - Any policy kit policies that need to be developed? The fact that JBOSS needs a static user makes me think that there are more opportunities for EAP to leverage platform identity capabilities in future. For RHEL6 and 7 verified that default uid/gid for jboss group/user after fresh EAP installation is 185 (For rhel6 and 7), if the uid/gid already exists it is chosen dynamically. RHEL5 doesn't have default uid/gid. Closing this bug as it was verified. |
Description of problem: Currently then the EAP product is being installed in the RPM version a jboss user and jboss group is being created, although it does not use static uid/gids: JBOSS_SHELL=/sbin/nologin %{_sbindir}/groupadd -r jboss 2>/dev/null || : %{_sbindir}/useradd -c JBossAS -r -s $JBOSS_SHELL -d %{_localstatedir}/lib/jbossas -g jboss jboss 2>/dev/null || : This is a problem, because the generated uid can conflict with some services. A static user and group id should be used. Additionally, in the Cloud Enablement team we are preparing initial Docker images for JBoss products. Every product will be used launched as a regular jboss user. We need to base on a registered uid/gid to not choose an ID that could possibly conflict with some other service. Using static uid/gid in Docker is crucial, because the system administrator need to know upfront the id's to set up the volumes permissions for the selected user.