Re: [Cooker] So, if 7.1 is now final...
That's the way that RedHat works, too. If I remember the RH doc set, every user is their own group, but can also be member of various "project" groups. - Original Message - From: "John Cavan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 03, 2000 10:58 AM Subject: Re: [Cooker] So, if 7.1 is now final... > Chmouel Boudjnah wrote: > > > > John Cavan <[EMAIL PROTECTED]> writes: > > > > > 2. When you create a normal user at install time it also creates a group > > > that matches the user. That means I get john:john instead of john:users > > > > this is the standard way on our distribution, a user has a group and > > after the administrator manage to set him on a different group. > > It may be the standard way on Mandrake, but it's not a standard way for > Unix... it is unexpected behaviour and you do have a group labled > "users" which I assume is for this purpose. It's not a big problem or > anything, I just can't see the reason for doing it that way. The last > thing any of us would want is a hundred different groups with the exact > same name as the user IDs in the system. > > John > > --- Jonathan M. Prigot
Re: [Cooker] So, if 7.1 is now final...
John Cavan <[EMAIL PROTECTED]> writes: > Anyways, enough said. I don't plan to modify the RPM, it's a maintenance > headache to keep doing that everytime an upgraded RPM comes down the > pipe, so I'll deal with the behaviour. a modified version of adduser in /usr/local/sbin/ ? it's what most admin doing -- MandrakeSoft Inchttp://www.mandrakesoft.com In travel.--Chmouel
Re: [Cooker] So, if 7.1 is now final...
John Grange wrote: > it is actualy very usefull because say you want user A to be able to access > files in a dirrectory but you do not want the people in the users group to be > able to access them, then you just set the gid of the dir to that users gid , > it's not stupid it's very usefull and i find i use it very often on my server. I didn't say it wasn't useful, I said it was counter-intuitive. There's a difference here. As I noted, the defaults of the system are specified (see /etc/default/useradd) but ignored by the software. That is not the expected behaviour of software. The way I normally do the behaviour you mention is: chmod 0700 xxx That allows only the user and root to access it, and is the normal way of implementing Unix security permissions. Bear in mind that the inutuitive model comes from people migrating from both Windows and traditional Unix systems. John
Re: [Cooker] So, if 7.1 is now final...
Geoffrey Lee wrote: > > patch the code yourself if youd on't like how it works :ppp No offense, but that's a crummy response to user feedback, a habit on this list I might add. Yes, I can patch the code, but that's not relevant to the discussion, nor can I do that during install. In actual fact, it's a question of NOT patching the code, as the "feature" has been added via a Redhat specific patch, take a look at the source RPM. I've been a Unix/Linux user for a long time and I spend a lot of time educating Windows users on the advantages of going with Linux, but it's less easy to do that when behaviour is counter-intuitive. The whole point of defaults is just that: defaults. It's EXPECTED behaviour of just about any software you encounter that the defaults are accepted in the absence of instructions to the contrary, otherwise why bother with defaults? The wrong answer, if we desire Linux to grow, is "patch the code". I can assure you that companies in the business of selling Linux want it to grow. Anyways, enough said. I don't plan to modify the RPM, it's a maintenance headache to keep doing that everytime an upgraded RPM comes down the pipe, so I'll deal with the behaviour. John
Re: [Cooker] So, if 7.1 is now final...
John Cavan wrote: > Chmouel Boudjnah wrote: > > > > John Cavan <[EMAIL PROTECTED]> writes: > > > > > 2. When you create a normal user at install time it also creates a group > > > that matches the user. That means I get john:john instead of john:users > > > > this is the standard way on our distribution, a user has a group and > > after the administrator manage to set him on a different group. > > It may be the standard way on Mandrake, but it's not a standard way for > Unix... it is unexpected behaviour and you do have a group labled > "users" which I assume is for this purpose. It's not a big problem or > anything, I just can't see the reason for doing it that way. The last > thing any of us would want is a hundred different groups with the exact > same name as the user IDs in the system. > > John it is actualy very usefull because say you want user A to be able to access files in a dirrectory but you do not want the people in the users group to be able to access them, then you just set the gid of the dir to that users gid , it's not stupid it's very usefull and i find i use it very often on my server. -DarkWlf
RE: [Cooker] So, if 7.1 is now final...
RH/Debian/Slack > > Fair enough, note I said Unix :o). I don't think they always did it that > way, it appears to be a logic change in useradd. I find it odd that it > was done that way, normally you shouldn't have to tell something to > explicitly take system defaults... it should be the other way around. > > Anyways, I personally, and that's just personally, think it's the wrong > way to do it, but as I said, it's not a big problem. I'll just have to > remember to add -D or -n to useradd when creating users. :o) > patch the code yourself if youd on't like how it works :ppp > John >
Re: [Cooker] So, if 7.1 is now final...
John Cavan <[EMAIL PROTECTED]> writes: > Anyways, I personally, and that's just personally, think it's the wrong > way to do it, but as I said, it's not a big problem. I'll just have to > remember to add -D or -n to useradd when creating users. :o) yep 8) -- MandrakeSoft Inchttp://www.mandrakesoft.com In travel.--Chmouel
Re: [Cooker] So, if 7.1 is now final...
Chmouel Boudjnah wrote: > > John Cavan <[EMAIL PROTECTED]> writes: > > > It may be the standard way on Mandrake, but it's not a standard way for > > Unix... it is unexpected behaviour and you do have a group labled > > it's the standard way on a Linux System see on a RH/Debian/Slack Fair enough, note I said Unix :o). I don't think they always did it that way, it appears to be a logic change in useradd. I find it odd that it was done that way, normally you shouldn't have to tell something to explicitly take system defaults... it should be the other way around. Anyways, I personally, and that's just personally, think it's the wrong way to do it, but as I said, it's not a big problem. I'll just have to remember to add -D or -n to useradd when creating users. :o) John
Re: [Cooker] So, if 7.1 is now final...
John Cavan <[EMAIL PROTECTED]> writes: > It may be the standard way on Mandrake, but it's not a standard way for > Unix... it is unexpected behaviour and you do have a group labled it's the standard way on a Linux System see on a RH/Debian/Slack -- MandrakeSoft Inchttp://www.mandrakesoft.com In travel.--Chmouel
Re: [Cooker] So, if 7.1 is now final...
Chmouel Boudjnah wrote: > > John Cavan <[EMAIL PROTECTED]> writes: > > > 2. When you create a normal user at install time it also creates a group > > that matches the user. That means I get john:john instead of john:users > > this is the standard way on our distribution, a user has a group and > after the administrator manage to set him on a different group. It may be the standard way on Mandrake, but it's not a standard way for Unix... it is unexpected behaviour and you do have a group labled "users" which I assume is for this purpose. It's not a big problem or anything, I just can't see the reason for doing it that way. The last thing any of us would want is a hundred different groups with the exact same name as the user IDs in the system. John
Re: [Cooker] So, if 7.1 is now final...
John Cavan <[EMAIL PROTECTED]> writes: > 2. When you create a normal user at install time it also creates a group > that matches the user. That means I get john:john instead of john:users this is the standard way on our distribution, a user has a group and after the administrator manage to set him on a different group. -- MandrakeSoft Inchttp://www.mandrakesoft.com In travel.--Chmouel
