New issue
Advanced search Search tips
Starred by 41 users
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature



Sign in to add a comment
Regarding Issue 126802, UI for creating Chrome Device hostnames, can this be in the Admin control panel
Reported by mike.el...@communitychoice.us, Dec 21 2016 Back to list
UserAgent: Mozilla/5.0 (X11; CrOS x86_64 8872.70.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Platform: 8872.70.0 (Official Build) stable-channel panther

Steps to reproduce the problem:
1. Open network router
2. Search for connected equipment
3. No information on Chrome OS devices

What is the expected behavior?
The ability to give devices on the network a name so they can be easily identified. Easier than identifying by IP address.

What went wrong?
They don't currently do this, https://bugs.chromium.org/p/chromium/issues/detail?id=126802#c64

Did this work before? No 

Chrome version: 55.0.2883.87  Channel: stable
OS Version: 8872.70.0
Flash Version: Shockwave Flash 23.0 r0

I'm unable to comment in the other thread, but I would like to request that this ability to add hostnames, if it is ever added, be added into the G Suite administration panel under Chrome Devices so I can assign hostnames to all my devices from a single convenient location.
 
Labels: -Type-Bug Type-Feature
Owner: dskaram@chromium.org
David to prioritize this FR
Comment 2 by dskaram@google.com, Jan 2 2017
Blockedon: 126802
We will def look into this once the source item is resolved.
Comment 3 by dskaram@google.com, Jan 2 2017
Status: Assigned
Comment 4 by dskaram@google.com, Jan 2 2017
Labels: -Pri-2 Pri-3
This is a HUGE need for us.  Please, Google, help with this situation.
I would like to be able to do this also for my devices.  Please add the feature.
Without having the hostname configurable and available, it makes troubleshooting wireless, dhcp, etc issues difficult.  Please add this so that we can add a hostname to our devices and then identify them in our router, switch, dhcp, etc client lists where connected hostnames are displayed.  Thanks!
This is a HUGE need for us, also.  Please, Google, help with this situation.
This would be a great help to us as well. Please Google.

Cc: cernekee@chromium.org atwilson@chromium.org dskaram@chromium.org
Labels: -Pri-3 Pri-2
Owner: antrim@chromium.org
The policy will be surfaced as a string in the admin UI. Values:

(default) no policy:               No DHCP option 12 attached - Existing behavior
Policy=xxx                         xxx
Policy=${ASSET_ID}                 Device's asset ID [1]
Policy=${SERIAL_NUM}               Device's serial number
Policy=${MAC_ADDR}                 Device's MAC address
Policy=xxx+VAR+xxx                 xxx+VAR_VALUE+xxx


[1] https://chromereleases.googleblog.com/2015/04/admin-console-update_8.html
Blockedon: -126802
So if we say that we have only 3 variables (ASSET_ID, SERIAL_NUM, MAC_ADDR) and we do simple case-sensitive string substitution for them, then we actually have only two options: 

(default) no policy:               No DHCP option 12 attached - Existing behavior
Policy=xxxVARxxx                 xxxVAR_VALUExxx

But we would need to validate hostname after, and this brings us to question "What to do if resulting hostname is invalid?". We do not want to set invalid host name, as it might either result in rejected DHCP request, or be a way to exploit DHCP server vulnerabilities. And at this point there are few ways we can use to indicate errors: system logging and setting some message-containing host name.
Cc: mnissler@chromium.org
I'd like for Cpanel to detect invalid hostnames, since this is the best place for the user to notice the error.

If an invalid hostname somehow makes it into the policy, shill can drop it and log an error.  This shouldn't normally happen, of course.

FWIW:

1) I don't see any validation of kHostnameProperty (hostname_) happening in $SHILL/dhcp/dhcpv4_config.cc so we should check that.  Same for vendor_class_.  Seeing string properties from Chrome getting copied directly into subprocess command-line arguments makes me nervous.

2) DhcpProperties::kHostnameProperty and DhcpProperties::kVendorClassProperty should probably be moved into dbus-constants.h in the system_api package so that Chrome can use them.
Re: cpanel detection, is this actually viable if we do client-side substitution of things like Asset ID?
Btw, Asset ID seem to have no validation - it can be arbitrary long, start with digits, contain weird UTF symbols, etc.

I believe we should have defend-it-depth here: sanity checks on at least 3 layers: ChromeOS (shill), Chrome (layer that applies policy) and CPanel (to prevent absurd values in policy).
If the Asset ID field is less restrictive than the Hostname field by design, I would suggest substituting (say) '_' for any disallowed characters found in the Asset ID, when shill creates the parameter to pass to dhcpcd.

For substitutions like "append the last 3 octets of the MAC address" (found in the doc we discussed over email), that should not present a validation problem, unless the final hostname string is too long.
tbh I would prefer not to work too hard on ensuring sanity of hostname. The admin is responsible for creating hostnames that fit into whatever use case they want to aim for. We can add warnings to admins so that they understand what they are getting themsevles into. But wouldn't do things like changing non-characters into _ and such. Seems quite overkill and unpredictable from an admin's perspective.
I normally wouldn't care either, but letting bad strings percolate into dhcpcd parameters or DHCP options could create security issues for software that isn't designed to handle them.
"_" isn't valid in DNS labels, only [-0-9a-zA-Z]
This is a limitation of hostnames, not a DNS limitation.

(DNS is not just for hostnames and hostnames are not just in DNS)

https://en.wikipedia.org/wiki/Internationalized_domain_name#Internationalizing_Domain_Names_in_Applications
Sign in to add a comment