Bill Campbell | 1 Jun 06:59 2009

Re: Changing a user's shell on CentOS Directory Server?

On Sun, May 31, 2009, Matt Harrington wrote:
>Should unprivileged users be able to change their shell with lchsh on
>5.3 and, if it matters, CentOS Directory Server?  lchsh seems to
>require more open permissions than those which come with a default
>installation:

Personally I would not permit uses to change their shells, but
require appropriate admin privileges.  I have seen systems hacks
made via webmin or usermin where the user's shell was changed
from /bin/false to /bin/bash, then the account used to install
user-level bots that definately should not have been there.

Most of our customers are regional ISPs or small-to-medium
businesses where most user accounts have /bin/false as their
shells as the average user has no need for shell access.  Any
user who wants real shell access needs to ask specifically for
it, and, in the case of the ISPs, be known to the ISP as somebody
who isn't going to abuse or misuse the account, intentionally or
through simple ignorance.

Bill
--

-- 
INTERNET:   bill@...  Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/  PO Box 820; 6641 E. Mercer Way
Voice:          (206) 236-1676  Mercer Island, WA 98040-0820
Fax:            (206) 232-9186  Skype: jwccsllc (206) 855-5792

Democracy Is Mob Rule with Income Taxes
Michael A. Peters | 1 Jun 11:45 2009
Picon

Re: Changing a user's shell on CentOS Directory Server?

Bill Campbell wrote:
> On Sun, May 31, 2009, Matt Harrington wrote:
>> Should unprivileged users be able to change their shell with lchsh on
>> 5.3 and, if it matters, CentOS Directory Server?  lchsh seems to
>> require more open permissions than those which come with a default
>> installation:
> 
> Personally I would not permit uses to change their shells, but
> require appropriate admin privileges.  I have seen systems hacks
> made via webmin or usermin where the user's shell was changed
> from /bin/false to /bin/bash, then the account used to install
> user-level bots that definately should not have been there.

Any tool that changes the shell should have a whitelist of shells the 
user account must currently be set to or it exits, and probably should 
validate the new shell is in that white list as well before it changes it.
Phil Schaffner | 1 Jun 15:29 2009
Picon

Re: turnoff monitor centos4.4 issue

karthikeyan subbannan wrote:
> hi all,
>            In centos 4.4 turnoff monitor is not working.Dpms is enable 
> and also change the dpms setting it working but not functioning.
>        I am using kde3.3  desktop.How to slove this....pls help me.

First thing to try would be to update to CentOS 4.7 - 4.8 will be out soon.

Phil
Phil Schaffner | 1 Jun 15:39 2009
Picon

Re: No libGL on this box - disabling OpenGL support !

madunix wrote:
> installed wine through the repo
> 
> [root <at> linux11 ~]# rpm -aq | grep -i wine
> wine-cms-1.0.1-1.el5
...
> 
> to build the wine i used the repo of epel and rpmforge
...

EPEL does not play nicely with RPMforge, and you seem to have both 
enabled with no yum-priorities plugin.  Please read

http://wiki.centos.org/AdditionalResources/Repositories
http://wiki.centos.org/PackageManagement/Yum/Priorities

If you have run updates with this configuration you have replaced core 
packages and probably also have an incompatible mix or RPMforge and EPEL.

Phil
Lanny Marcus | 1 Jun 17:47 2009
Picon

Re: No libGL on this box - disabling OpenGL support !

On Mon, Jun 1, 2009 at 8:39 AM, Phil Schaffner
<Philip.R.Schaffner@...> wrote:
> madunix wrote:
>> installed wine through the repo
>> [root <at> linux11 ~]# rpm -aq | grep -i wine
>> wine-cms-1.0.1-1.el5
>> to build the wine i used the repo of epel and rpmforge
>
> EPEL does not play nicely with RPMforge, and you seem to have both
> enabled with no yum-priorities plugin.  Please read
>
> http://wiki.centos.org/AdditionalResources/Repositories
> http://wiki.centos.org/PackageManagement/Yum/Priorities
>
In addition to adding yum-priorities, I would suggest giving EPEL a
much lower priority than RPMforge.   When I added the EPEL repository,
there was a huge increase in the number of excluded packages.
<snip>
Les Mikesell | 1 Jun 18:43 2009
Picon

stock openjdk vs. epel

If you have the epel repo installed and enabled during a yum update, you 
get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 
version.  Is this intentional and desirable?  I thought epel generally 
did not replace stock components with newer versions.

--

-- 
   Les Mikesell
    lesmikesell@...
Scott Silva | 1 Jun 19:31 2009
Picon

Re: stock openjdk vs. epel

on 6-1-2009 9:43 AM Les Mikesell spake the following:
> If you have the epel repo installed and enabled during a yum update, you 
> get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 
> version.  Is this intentional and desirable?  I thought epel generally 
> did not replace stock components with newer versions.
> 
Any third party repo has the potential to replace base files. That is why the
priorities and the protectbase plugins were written.

_______________________________________________
CentOS mailing list
CentOS@...
http://lists.centos.org/mailman/listinfo/centos
Les Mikesell | 1 Jun 19:49 2009
Picon

Re: stock openjdk vs. epel

Scott Silva wrote:
> on 6-1-2009 9:43 AM Les Mikesell spake the following:
>> If you have the epel repo installed and enabled during a yum update, you 
>> get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 
>> version.  Is this intentional and desirable?  I thought epel generally 
>> did not replace stock components with newer versions.
>>
> Any third party repo has the potential to replace base files. That is why the
> priorities and the protectbase plugins were written.

Obviously they have the potential - and almost equally obviously an end 
user will have no idea what to choose even if they do have a tiny bit of 
control over yum (but no way to see where their existing version came 
from).  But I thought that long ago I asked if epel would supply a newer 
Firefox or OpenOffice (back when it was needed and RHEL hadn't done it 
yet...) and someone replied that it would not be epel policy to 
overwrite stock packages.  Was that not correct - or have things changed?

--

-- 
   Les Mikesell
    lesmikesell@...
Lanny Marcus | 1 Jun 19:50 2009
Picon

Re: stock openjdk vs. epel

On Mon, Jun 1, 2009 at 12:31 PM, Scott Silva <ssilva@...> wrote:
> on 6-1-2009 9:43 AM Les Mikesell spake the following:
>> If you have the epel repo installed and enabled during a yum update, you
>> get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09
>> version.  Is this intentional and desirable?  I thought epel generally
>> did not replace stock components with newer versions.
>>
> Any third party repo has the potential to replace base files. That is why the
> priorities and the protectbase plugins were written.

On my CentOS 5 Desktop, when I added the EPEL repository, and gave it
a very low priority,  the number of excluded packages more than
quadrupled. "1648 packages excluded due to repository priority
protections"
Scott Silva | 1 Jun 21:09 2009
Picon

Re: stock openjdk vs. epel

on 6-1-2009 10:49 AM Les Mikesell spake the following:
> Scott Silva wrote:
>> on 6-1-2009 9:43 AM Les Mikesell spake the following:
>>> If you have the epel repo installed and enabled during a yum update, you 
>>> get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 
>>> version.  Is this intentional and desirable?  I thought epel generally 
>>> did not replace stock components with newer versions.
>>>
>> Any third party repo has the potential to replace base files. That is why the
>> priorities and the protectbase plugins were written.
> 
> Obviously they have the potential - and almost equally obviously an end 
> user will have no idea what to choose even if they do have a tiny bit of 
> control over yum (but no way to see where their existing version came 
> from).  But I thought that long ago I asked if epel would supply a newer 
> Firefox or OpenOffice (back when it was needed and RHEL hadn't done it 
> yet...) and someone replied that it would not be epel policy to 
> overwrite stock packages.  Was that not correct - or have things changed?
> 
EPEL was also asked if they could add a repo tag just so people knew where
things came from. That didn't happen either, but much "discussion" did happen.
As for EPEL policy, I guess you will have to ask them. Since it is Fedora
packages being rebuilt, there is going to have to be some newer things being
put in there.

_______________________________________________
CentOS mailing list
CentOS@...
(Continue reading)


Gmane