1 |
On 14/03/2015 20:53, Matti Nykyri wrote: |
2 |
>> On Mar 14, 2015, at 12:47, German <gentgerman@×××××.com> wrote: |
3 |
>> |
4 |
>> On Sat, 14 Mar 2015 10:33:59 +0000 |
5 |
>> Neil Bothwick <neil@××××××××××.uk> wrote: |
6 |
>> |
7 |
>>> On Sat, 14 Mar 2015 06:08:34 -0400, German wrote: |
8 |
>>> |
9 |
>>>>> Forget about "chmod 770". Better do a "chmod g+rw". :-) |
10 |
>>>> |
11 |
>>>> Tried it, it also doesn't stay permanently. OK, no solution :( |
12 |
>>> |
13 |
>>> The correct solution is a udev rule, but it appears that something may be |
14 |
>>> overriding that when you login. |
15 |
>> |
16 |
>> I have the same udev rule. Yes, something is overriding it. |
17 |
>> |
18 |
>> A kludgy solution is to add the chmod |
19 |
>>> command to ~/.bash_profile. |
20 |
> |
21 |
> Don't hit your head to a brick wall. A small strace to the login process reveals that login set things as you tell it to in /etc/login.defs |
22 |
> |
23 |
> In this file change the line: |
24 |
> TTYPERM 0600 |
25 |
> To: |
26 |
> TTYPERM 0620 |
27 |
> |
28 |
> And your problem is fixed. |
29 |
> |
30 |
> The problem has nothing to do with udev. If you don't like a volatile /dev just remove udev and create everything you wan't by hand (not recommended ;) |
31 |
> |
32 |
> Another thing i'm puzzled by is, why do you wan't to login as root and the su to someone else? I usually do it the other way around... |
33 |
> |
34 |
|
35 |
|
36 |
There is a use-case for doing it (but I highly doubt the OP is using it) |
37 |
|
38 |
Take a system user like eg sybase or rancid. You can't run those apps as |
39 |
root (it messes with permissions etc, and some scripts detect EUID 0 and |
40 |
refuse to run). The sybase and rancid users can't log in at all, and the |
41 |
system is set up so I can't su as me to that account directly. So I have |
42 |
to go from my login account to root then drop privs to the system user. |
43 |
|
44 |
-- |
45 |
Alan McKinnon |
46 |
alan.mckinnon@×××××.com |