hi,
Cockpit 169 (released today) contains a change to take advantage of the recently added PAM support for /etc/motd.d to display a helpful note to the admin about how to start or access cockpit.
The required PAM changes have already landed in Fedora 28.
It seems that the PAM configuration of Fedora 28 (at least in our test images here) doesn't use pam_motd at all, though.
I'd like to start a discussion about what would be appropriate here. We want at least a message displayed when people log in to an interactive session with ssh, but it might also be useful to display a message at the virtual console, before or after login.
Thoughts?
Thanks in advance,
Allison
On Wed, May 30, 2018 at 8:52 AM Allison Karlitskaya < allison.karlitskaya@redhat.com> wrote:
hi,
Cockpit 169 (released today) contains a change to take advantage of the recently added PAM support for /etc/motd.d to display a helpful note to the admin about how to start or access cockpit.
The required PAM changes have already landed in Fedora 28.
It seems that the PAM configuration of Fedora 28 (at least in our test images here) doesn't use pam_motd at all, though.
I'd like to start a discussion about what would be appropriate here. We want at least a message displayed when people log in to an interactive session with ssh, but it might also be useful to display a message at the virtual console, before or after login.
Thoughts?
I had a short conversation about this on IRC with Allison and Martin Pitt which I'll summarize for the wider discussion, as well as including some additional thoughts I've had while typing.
The current state on Fedora Server is that we have a specialized version of /etc/issue that will display something along the lines of: Admin Console: https://0.0.0.0:9090/ or https://%5B::::%5D:9090/ (with the actual public IP address of the machine there)
Cockpit has recently grown the capability to generate certain files when the cockpit.socket unit is started, allowing us to have more control over what messages we want people to see. In particular, Cockpit 169 now has the ability to generate files in /etc/motd.d that will enable systems that have pam_motd.so in their PAM session stack to display the Cockpit console address after the user logs in. These generated files can also insert the machine's public hostname instead of the simple IP address we have now, which will play better with SSL Certificates.
Today, the /etc/issue implementation is only seen by people who can see a console login, either by having a keyboard and monitor attached to the machine or else via a physical or virtual serial connection. With this new pam_motd.so implementation, we will be able to inform users about the admin console who are using other login mechanisms, most notably SSH.
However, this will require modification of the default configuration on Fedora Server (at minimum) or possibly Fedora in general. Presently, no PAM stack shipped by default on Fedora includes pam_motd.so. I think that the value of having Cockpit information in the MOTD is worthwhile, so we should consider adding it to at least the SSHD PAM stack, so that users who have only remote access to the machines can still be informed of the availability of the Cockpit admin console.
Another approach would be to make it more generally available by adding it to the 'postlogin' PAM stack, which would mean that the MOTD would be seen by anyone logging in via any standard login mechanism. If we did this, we'd assuredly remove the /etc/issue implementation, as it would be redundant. The downside to this is that the default configuration for postlogin is to also run on things like `su` and `sudo -i`, so that could be noisy. We could deak with this by splitting the 'postlogin' stack into one that handled "real" logins (sshd, getty, etc.) and one that handles local privilege escalations (su, sudo, etc.). This would require coordination with the PAM maintainers in Fedora.
The middle-ground approach would be to add pam_motd.so solely to the SSHD PAM stack and then leave /etc/issue to display the console for local purposes. The Cockpit folks can chime in if I've gotten this right, but apparently there's a newer way we can generate the /etc/issue content so that it can now display the hostname as well. So we'd retire the current way we're doing it for IP addresses. The benefit to this approach is that for rack-mounted systems that probably have a common serial interface console (or just a rolling cart monitor), the user can just glance at the login prompt and see that Cockpit is available without requiring them to log in first.
I'm looking for us to come to a general consensus on how we present this information to the user. I'd appreciate any input you might be willing to provide.
Thank you for reading to the end, I know it was a long one.
hi Stephen,
On Wed, May 30, 2018 at 3:17 PM, Stephen Gallagher sgallagh@redhat.com wrote:
However, this will require modification of the default configuration on Fedora Server (at minimum) or possibly Fedora in general. Presently, no PAM stack shipped by default on Fedora includes pam_motd.so. I think that the value of having Cockpit information in the MOTD is worthwhile, so we should consider adding it to at least the SSHD PAM stack, so that users who have only remote access to the machines can still be informed of the availability of the Cockpit admin console.
Another approach would be to make it more generally available by adding it to the 'postlogin' PAM stack, which would mean that the MOTD would be seen by anyone logging in via any standard login mechanism. If we did this, we'd assuredly remove the /etc/issue implementation, as it would be redundant. The downside to this is that the default configuration for postlogin is to also run on things like `su` and `sudo -i`, so that could be noisy. We could deak with this by splitting the 'postlogin' stack into one that handled "real" logins (sshd, getty, etc.) and one that handles local privilege escalations (su, sudo, etc.). This would require coordination with the PAM maintainers in Fedora.
The middle-ground approach would be to add pam_motd.so solely to the SSHD PAM stack and then leave /etc/issue to display the console for local purposes. The Cockpit folks can chime in if I've gotten this right, but apparently there's a newer way we can generate the /etc/issue content so that it can now display the hostname as well. So we'd retire the current way we're doing it for IP addresses. The benefit to this approach is that for rack-mounted systems that probably have a common serial interface console (or just a rolling cart monitor), the user can just glance at the login prompt and see that Cockpit is available without requiring them to log in first.
You've characterised the situation fairly accurately.
imho, adding pam_motd for SSH is the reasonable thing to do here.
As for the /etc/issue question, that's rather easy to deal with as well. /etc/motd.d/cockpit is just a symlink to /run/cockpit/motd (which itself is always a link to the appropriate text to display). We could just add another link for /etc/issue.d/cockpit, and reuse the same text. I could add this link to cockpit upstream, if that's what we decide to do.
Allison
On Wed, May 30, 2018 at 9:42 AM Allison Karlitskaya < allison.karlitskaya@redhat.com> wrote:
hi Stephen,
On Wed, May 30, 2018 at 3:17 PM, Stephen Gallagher sgallagh@redhat.com wrote:
However, this will require modification of the default configuration on Fedora Server (at minimum) or possibly Fedora in general. Presently, no PAM stack shipped by default on Fedora includes pam_motd.so. I think that the value of having Cockpit information in the MOTD is worthwhile, so we should consider adding it to at least the SSHD PAM stack, so that users who have only remote access to the machines can still be informed of the availability of the Cockpit admin console.
Another approach would be to make it more generally available by adding it to the 'postlogin' PAM stack, which would mean that the MOTD would be seen by anyone logging in via any standard login mechanism. If we did this, we'd assuredly remove the /etc/issue implementation, as it would be redundant. The downside to this is that the default configuration for postlogin is to also run on things like `su` and `sudo -i`, so that could be noisy. We could deak with this by splitting the 'postlogin' stack into one that handled "real" logins (sshd, getty, etc.) and one that handles local privilege escalations (su, sudo, etc.). This would require coordination with the PAM maintainers in Fedora.
The middle-ground approach would be to add pam_motd.so solely to the SSHD PAM stack and then leave /etc/issue to display the console for local purposes. The Cockpit folks can chime in if I've gotten this right, but apparently there's a newer way we can generate the /etc/issue content so that it can now display the hostname as well. So we'd retire the current way we're doing it for IP addresses. The benefit to this approach is that for rack-mounted systems that probably have a common serial interface console (or just a rolling cart monitor), the user can just glance at the login prompt and see that Cockpit is available without requiring them to log in first.
You've characterised the situation fairly accurately.
imho, adding pam_motd for SSH is the reasonable thing to do here.
As for the /etc/issue question, that's rather easy to deal with as well. /etc/motd.d/cockpit is just a symlink to /run/cockpit/motd (which itself is always a link to the appropriate text to display). We could just add another link for /etc/issue.d/cockpit, and reuse the same text. I could add this link to cockpit upstream, if that's what we decide to do.
This is definitely the simplest and least-invasive approach we can take. It probably has the highest cost-benefit ratio as well. I think the noise level is too high for adding it to postlogin and breaking that up into multiple stack snippets seems like an unnecessary amount of work for the benefit. (Sure, it would work for someone who decided to log in via rsh, but do we really want to encourage that?)
Assuming we took this approach, the remaining question is whether we want to do this for Server Edition only, or if we should take this to Fedora as a whole. I personally think that there's no particular need to restrict this to Server Edition; if someone on Workstation or KDE or Atomic decides to have Cockpit active and listening, we should probably inform their users about it. I think we should file a Self-Contained Change Proposal[1] so that FESCo can approve it for general use. I'd be happy to co-own this Change.
Hello Stephen,
Stephen Gallagher [2018-05-30 9:49 -0400]:
imho, adding pam_motd for SSH is the reasonable thing to do here.
Considering the alternatives, I agree. That plus dropping the Fedora Server specific /etc/issue, and using /etc/issue.d/cockpit instead.
As for the /etc/issue question, that's rather easy to deal with as well. /etc/motd.d/cockpit is just a symlink to /run/cockpit/motd (which itself is always a link to the appropriate text to display). We could just add another link for /etc/issue.d/cockpit, and reuse the same text. I could add this link to cockpit upstream, if that's what we decide to do.
This is definitely the simplest and least-invasive approach we can take. It probably has the highest cost-benefit ratio as well.
I hope you mean "lowest"? :-)
Assuming we took this approach, the remaining question is whether we want to do this for Server Edition only, or if we should take this to Fedora as a whole. I personally think that there's no particular need to restrict this to Server Edition; if someone on Workstation or KDE or Atomic decides to have Cockpit active and listening, we should probably inform their users about it.
Agreed. Conversely, if someone uninstalls cockpit, they should no longer see this message. This is why a static /etc/issue is quite bad, aside from the usability problems [1].
[1] showing long IP numbers really isn't helpful on a console, where you don't even have copy&paste - and they are not what humans use to identify a machine, that's why we invented names and DNS
Summarizing the proposal:
* Drop the Fedora Server specific /etc/issue * Land https://github.com/cockpit-project/cockpit/pull/9274 to provide a dynamic issue.d/ replacement for the above * Add pam_motd to /etc/pam.d/sshd
Thanks!
Martin
This is definitely the simplest and least-invasive approach we can take.
It
probably has the highest cost-benefit ratio as well.
I hope you mean "lowest"? :-)
Highest benefit! That phrase is really awkward in English.
Assuming we took this approach, the remaining question is whether we want to do this for Server Edition only, or if we should take this to Fedora
as
a whole. I personally think that there's no particular need to restrict this to Server Edition; if someone on Workstation or KDE or Atomic
decides
to have Cockpit active and listening, we should probably inform their
users
about it.
Agreed. Conversely, if someone uninstalls cockpit, they should no longer see this message. This is why a static /etc/issue is quite bad, aside from the usability problems [1].
[1] showing long IP numbers really isn't helpful on a console, where you don't even have copy&paste - and they are not what humans use to identify a machine, that's why we invented names and DNS
Summarizing the proposal:
- Drop the Fedora Server specific /etc/issue
- Land https://github.com/cockpit-project/cockpit/pull/9274 to provide a dynamic issue.d/ replacement for the above
- Add pam_motd to /etc/pam.d/sshd
Yes, this sounds like the best approach to me. No one else seems to be chiming in to disagree, so let’s move ahead with this. I’ll send a PR for F28 and F29 to drop the /etc/issue from Server on fedora-release shortly. I assume you will bring the issue.d change back to F28’s Cockpit?
Hello Stephen,
Stephen Gallagher [2018-06-01 6:15 -0400]:
Yes, this sounds like the best approach to me. No one else seems to be chiming in to disagree, so let’s move ahead with this.
Agreed, thanks.
I’ll send a PR for F28 and F29 to drop the /etc/issue from Server on fedora-release shortly.
I think it's safe to say that this should/would happen with any solution (pam.d/postlogin, issue.d/cockpit, or any combination), so this is a nice cleanup.
I assume you will bring the issue.d change back to F28’s Cockpit?
Yes, I will.
Thanks!
Martin
Hello Stephen,
Stephen Gallagher [2018-06-01 6:15 -0400]:
- Drop the Fedora Server specific /etc/issue
- Land https://github.com/cockpit-project/cockpit/pull/9274 to provide a dynamic issue.d/ replacement for the above
Done in 170 (https://bodhi.fedoraproject.org/updates/cockpit-170-1.fc28)
- Add pam_motd to /etc/pam.d/sshd
Yes, this sounds like the best approach to me. No one else seems to be chiming in to disagree, so let’s move ahead with this. I’ll send a PR for F28 and F29 to drop the /etc/issue from Server on fedora-release shortly. I assume you will bring the issue.d change back to F28’s Cockpit?
No further replies, so I think we should go ahead with this plan. Do you want me to file bugzillas for dropping /etc/issue and adding pam_motd?
Thanks,
Martin
Yes, please do. On Thu, Jun 14, 2018 at 5:37 AM Martin Pitt mpitt@redhat.com wrote:
Hello Stephen,
Stephen Gallagher [2018-06-01 6:15 -0400]:
- Drop the Fedora Server specific /etc/issue
- Land https://github.com/cockpit-project/cockpit/pull/9274 to
provide a
dynamic issue.d/ replacement for the above
Done in 170 (https://bodhi.fedoraproject.org/updates/cockpit-170-1.fc28)
- Add pam_motd to /etc/pam.d/sshd
Yes, this sounds like the best approach to me. No one else seems to be chiming in to disagree, so let’s move ahead with this. I’ll send a PR for F28 and F29 to drop the /etc/issue from Server on fedora-release
shortly. I
assume you will bring the issue.d change back to F28’s Cockpit?
No further replies, so I think we should go ahead with this plan. Do you want me to file bugzillas for dropping /etc/issue and adding pam_motd?
Thanks,
Martin
Hello Stephen,
Stephen Gallagher [2018-06-14 6:45 -0400]:
No further replies, so I think we should go ahead with this plan. Do you want me to file bugzillas for dropping /etc/issue and adding pam_motd?
Done: https://bugzilla.redhat.com/show_bug.cgi?id=1591389 https://bugzilla.redhat.com/show_bug.cgi?id=1591381
Martin
I support displaying the contents of files in /etc/motd.d/*, but:
- Why only for ssh logins? What about console logins? What about graphical desktop logins? Why should that users not see this messages?
- Why should a normal user see a message like "Activate the web console with: systemctl enable --now cockpit.socket" ? A normal user cannot do that! But an administrator doesn't need this message - he / she knows systemctl command and / or can read the documentation!
There should be at least a configuration option if cockpit-ws generates this message! The default should be off - because administrators should be able to install the same list of packages on many different hosts (workstations, servers, notebooks, virtual machines, etc.) but run different services and use cases on them.
Now I need to uninstall cockpit-ws to get rid of this cockpit messages! I cannot even disable cockpit-motd.service because it is static! Thats very bad!
On Thu, Jun 14, 2018 at 6:02 PM Edgar Hoch edgar.hoch@ims.uni-stuttgart.de wrote:
I support displaying the contents of files in /etc/motd.d/*, but:
- Why only for ssh logins? What about console logins? What about graphical
desktop logins? Why should that users not see this messages?
For console logins, the user will get this message displayed as part of /etc/issue, which is visible *before* logging in. That's preferable, since it may save them some time.
- Why should a normal user see a message like
"Activate the web console with: systemctl enable --now cockpit.socket" ? A normal user cannot do that!
That's a valid point; we should figure out if we can limit this to certain users somehow (maybe members of the %wheel group).
But an administrator doesn't need this message - he / she knows systemctl command and / or can read the documentation!
That's contrary to the intent here, which is to be helpful to *new* administrators. One of the goals of Cockpit is to help new administrators get familiar with the system. So making assumptions that an administrator should just know that a console is available and they have to google a command to install it is a bad user experience.
There should be at least a configuration option if cockpit-ws generates this message! The default should be off - because administrators should be able to install the same list of packages on many different hosts (workstations, servers, notebooks, virtual machines, etc.) but run different services and use cases on them.
Again, no. The default is to help new people figure out what to do with their system. I agree, the directions to activate the console is probably unhelpful to a non-administrative user. So we *should* see if we can limit its exposure and if not we should probably not display it.
Now I need to uninstall cockpit-ws to get rid of this cockpit messages! I cannot even disable cockpit-motd.service because it is static! Thats very bad!
Sure you can, that's exactly the point of `systemctl mask`. Oh, did you not know that command? I would assume that ALL administrators would know it... wasn't that your argument above? (I joke, but I'm trying to make the point that we cannot assume our users - even the experienced ones - know everything about the system).
On Thu, Jun 14, 2018 at 6:02 PM Edgar Hoch edgar.hoch@ims.uni-stuttgart.de wrote:
I support displaying the contents of files in /etc/motd.d/*, but:
- Why only for ssh logins? What about console logins? What about graphical
desktop logins? Why should that users not see this messages?
Sorry, I forgot to mention that in the case of desktop logins, cockpit-ws also ships a .desktop file, so it will show up in whichever menu system the DE provides. So it can be discovered that way.
Hello Edgar,
Stephen already answered some bits, here's the other one:
Edgar Hoch [2018-06-14 22:01 -0000]:
- Why should a normal user see a message like
"Activate the web console with: systemctl enable --now cockpit.socket" ? A normal user cannot do that!
A normal user can access the Cockpit UI once it's enabled, though. But I'm afraid that pam_motd doesn't make the distinction between admin and user.
But an administrator doesn't need this message - he / she knows systemctl command and / or can read the documentation!
The point is less about teaching systemd, but to point out that a web console (Cockpit) exists, and which unit to enable.
There should be at least a configuration option if cockpit-ws generates this message! The default should be off - because administrators should be able to install the same list of packages on many different hosts (workstations, servers, notebooks, virtual machines, etc.) but run different services and use cases on them.
Default off would be completely meaningless, then we wouldn't need to show it at all. People who know about cockpit.socket don't need to be told that it exists.
Now I need to uninstall cockpit-ws to get rid of this cockpit messages! I cannot even disable cockpit-motd.service because it is static! Thats very bad!
No, you just need to remove /etc/motd.d/cockpit, that's sufficient and persistent.
Martin
Default off would be completely meaningless, then we wouldn't need to show it at all. People who know about cockpit.socket don't need to be told that it exists.
No, you just need to remove /etc/motd.d/cockpit, that's sufficient and persistent.
I just spent about 1/2 hour trying to figure out the proper way to disable this motd, I found no documentation other than the above comment.
It's unusual to modify a configuration by deleting installed files.
It's annoying to have administration information on how to use the system in a motd, by this logic we could have just about every software package that has some sort of API add a note to the motd on how to access it.
Where's the httpd motd to "Connet to http://somewhere.com to access your web page." :-(
Or the ssh motd "Login using ssh on port 22 to host somewhere.com" ;-)
Static information - a message that will not change - should not be in the motd.
Please get rid of this motd.
-- Patrick
Am 30.12.18 um 18:33 schrieb Patrick Mansfield:
Default off would be completely meaningless, then we wouldn't need to show it at all. People who know about cockpit.socket don't need to be told that it exists.
No, you just need to remove /etc/motd.d/cockpit, that's sufficient and persistent.
I just spent about 1/2 hour trying to figure out the proper way to disable this motd, I found no documentation other than the above comment.
It's unusual to modify a configuration by deleting installed files.
don't work because it get re-installed, the proper way is just to make this file empty and so it won't come back because thats rpmsave/rpmnew works by design
On Sun, Dec 30, 2018 at 12:33 PM Patrick Mansfield patmans@comcast.net wrote:
Default off would be completely meaningless, then we wouldn't need to
show it
at all. People who know about cockpit.socket don't need to be told that
it
exists.
No, you just need to remove /etc/motd.d/cockpit, that's sufficient and persistent.
I just spent about 1/2 hour trying to figure out the proper way to disable this motd, I found no documentation other than the above comment.
It's unusual to modify a configuration by deleting installed files.
It's annoying to have administration information on how to use the system in a motd, by this logic we could have just about every software package that has some sort of API add a note to the motd on how to access it.
Where's the httpd motd to "Connet to http://somewhere.com to access your web page." :-(
Or the ssh motd "Login using ssh on port 22 to host somewhere.com" ;-)
Static information - a message that will not change - should not be in the motd.
Please get rid of this motd.
First of all, this is not exactly static information. The same mechanism that informs the user of how to start Cockpit also provides specific information about how to access it (including system-specific hostname and IP) once it has been started. It appears static if you never run the service, though.
I had an idea this morning, however. Once Cockpit is started, the MOTD provides useful information to all users logging in, so that needs to stay. The “how to start” message could probably be restricted to showing only to those users who are known to be capable of starting it (generally, root and members of the “wheel” group).
I need to test an idea (I’m on holiday today, back in the office tomorrow), but I think what we could do is set the ownership of the static MOTD to root:wheel and mode 0640. As long as pam_motd handles permission errors gracefully, it would only display that message to someone who met that criteria.
Yes, there could be non-wheel members who have sudo privilege to start services, but I think that falls safely into the edge-case of “people who already know what they’re doing”.
The point of this is to help out the people experimenting with Linux. (Such as those looking to convert from other popular server OSes.) We want to make sure that the “front door” is welcoming; providing people with a blinking cursor and no clear idea how to get anything done is a good way to lose potential converts. So I definitely think we need to retain these cues. But as I mentioned above l, I think we can target it a bit better.
Hello all,
Stephen Gallagher [2019-01-01 9:14 -0500]:
I had an idea this morning, however. Once Cockpit is started, the MOTD provides useful information to all users logging in, so that needs to stay. The “how to start” message could probably be restricted to showing only to those users who are known to be capable of starting it (generally, root and members of the “wheel” group).
I need to test an idea (I’m on holiday today, back in the office tomorrow), but I think what we could do is set the ownership of the static MOTD to root:wheel and mode 0640. As long as pam_motd handles permission errors gracefully, it would only display that message to someone who met that criteria.
pam_motd should handle absent files gracefully, we already tested it with dangling symlinks and such. However, it seems pam_motd does not actually run with the user privileges, but with root's? I tested your idea of making the file inaccessible (root:wheel 640), but it doesn't work:
| $ ssh test@127.0.0.2 | test@127.0.0.2's password: | Activate the web console with: systemctl enable --now cockpit.socket | | Last login: Wed Jan 16 05:11:16 2019 from 172.27.0.2 | [test@m1 ~]$ cat /etc/motd.d/cockpit | cat: /etc/motd.d/cockpit: Permission denied
Martin
On Wed, Jan 16, 2019 at 5:14 AM Martin Pitt mpitt@redhat.com wrote:
Hello all,
Stephen Gallagher [2019-01-01 9:14 -0500]:
I had an idea this morning, however. Once Cockpit is started, the MOTD provides useful information to all users logging in, so that needs to
stay.
The “how to start” message could probably be restricted to showing only
to
those users who are known to be capable of starting it (generally, root
and
members of the “wheel” group).
I need to test an idea (I’m on holiday today, back in the office
tomorrow),
but I think what we could do is set the ownership of the static MOTD to root:wheel and mode 0640. As long as pam_motd handles permission errors gracefully, it would only display that message to someone who met that criteria.
pam_motd should handle absent files gracefully, we already tested it with dangling symlinks and such. However, it seems pam_motd does not actually run with the user privileges, but with root's? I tested your idea of making the file inaccessible (root:wheel 640), but it doesn't work:
| $ ssh test@127.0.0.2 | test@127.0.0.2's password: | Activate the web console with: systemctl enable --now cockpit.socket | | Last login: Wed Jan 16 05:11:16 2019 from 172.27.0.2 | [test@m1 ~]$ cat /etc/motd.d/cockpit | cat: /etc/motd.d/cockpit: Permission denied
Oops, I thought I’d followed up on this. I tried it out and found the same, but I got distracted and must not have continued on this thread. Yeah, for some reason it looks like it runs before the permission drop in the open_session() phase. I was going to dive in deeper and then other priorities took hold, but I’ll put it on my list for today.
On Wed, Jan 16, 2019 at 5:54 AM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Jan 16, 2019 at 5:14 AM Martin Pitt mpitt@redhat.com wrote:
Hello all,
Stephen Gallagher [2019-01-01 9:14 -0500]:
I had an idea this morning, however. Once Cockpit is started, the MOTD provides useful information to all users logging in, so that needs to stay. The “how to start” message could probably be restricted to showing only to those users who are known to be capable of starting it (generally, root and members of the “wheel” group).
I need to test an idea (I’m on holiday today, back in the office tomorrow), but I think what we could do is set the ownership of the static MOTD to root:wheel and mode 0640. As long as pam_motd handles permission errors gracefully, it would only display that message to someone who met that criteria.
pam_motd should handle absent files gracefully, we already tested it with dangling symlinks and such. However, it seems pam_motd does not actually run with the user privileges, but with root's? I tested your ide, a of making the file inaccessible (root:wheel 640), but it doesn't work:
OK, so while pam_open_session() runs with UID == the user logging in, it *also* runs with EUID (effective UID) of the application that called it. This is so that pam_open_session() can do things like creating or mounting the user's home directory.
So, we cannot rely on basic permissions to restrict the display of the MOTD (without modifying pam_motd sources). I guess that would have been too easy...
Am 16.01.19 um 15:32 schrieb Stephen Gallagher:
OK, so while pam_open_session() runs with UID == the user logging in, it *also* runs with EUID (effective UID) of the application that called it. This is so that pam_open_session() can do things like creating or mounting the user's home directory.
So, we cannot rely on basic permissions to restrict the display of the MOTD (without modifying pam_motd sources). I guess that would have been too easy...
when it is properly packaged as "confignoreplace" just empty that file and you are done
On Wed, Jan 16, 2019 at 9:46 AM Reindl Harald h.reindl@thelounge.net wrote:
Am 16.01.19 um 15:32 schrieb Stephen Gallagher:
OK, so while pam_open_session() runs with UID == the user logging in, it *also* runs with EUID (effective UID) of the application that called it. This is so that pam_open_session() can do things like creating or mounting the user's home directory.
So, we cannot rely on basic permissions to restrict the display of the MOTD (without modifying pam_motd sources). I guess that would have been too easy...
when it is properly packaged as "confignoreplace" just empty that file and you are done
That is entirely unrelated to the discussion at hand. The idea was to have the file readable only by root/wheel when cockpit is not running, so only the users with the ability to start cockpit would see the message. Then, when cockpit starts it would be replaced by a world-readable version that includes the address.
Read and acknowledged
On Sun, Dec 30, 2018, 12:33 PM Patrick Mansfield <patmans@comcast.net wrote:
Default off would be completely meaningless, then we wouldn't need to
show it
at all. People who know about cockpit.socket don't need to be told that
it
exists.
No, you just need to remove /etc/motd.d/cockpit, that's sufficient and persistent.
I just spent about 1/2 hour trying to figure out the proper way to disable this motd, I found no documentation other than the above comment.
It's unusual to modify a configuration by deleting installed files.
It's annoying to have administration information on how to use the system in a motd, by this logic we could have just about every software package that has some sort of API add a note to the motd on how to access it.
Where's the httpd motd to "Connet to http://somewhere.com to access your web page." :-(
Or the ssh motd "Login using ssh on port 22 to host somewhere.com" ;-)
Static information - a message that will not change - should not be in the motd.
Please get rid of this motd.
-- Patrick _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org
server@lists.fedoraproject.org
-
Allison Karlitskaya -
Cody Sicher -
Edgar Hoch -
Martin Pitt -
Patrick Mansfield -
Reindl Harald -
Stephen Gallagher