On Tue, Jun 30, 2009 at 8:51 PM, Steve Phillips <steve.phillips@xxxxxxxxx>wrote: > On 6/30/09, hike <mh1272@xxxxxxxxx> wrote: > [lots of redundant stuff snipped] > > > > not really. > > > > any time the op oversteps his authorized usage of a machine, he has > crossed > > the line. > > > > so, whether he is a user trying to gain root access or a sudo-er trying > to > > gain root access, he is doing the same thing in either case--the gaining > of > > increased right that he is now authorized to gain. > > > > just because the op has some rights (and we don't know that is the case), > > there is no approval beyond those rights; the taking of unapproved rights > > was the topic i was discussing and it appears that the op is purposing to > > take unapproved rights. > > After re-reading your posts and the context its become quite apparent > that you are jumping to conclusions about how things could potentially > work in the real world. > > (not to mention that your ambiguous abbreviations make things harder > to understand what it is exactly that you are trying to say, are you > implying that the op (original poster) is trying to hack the system or > the op (operator) or is there some other abbreviation of 'op' that I'm > unaware of ?) > > As a real world example (and this is used a _lot_ in the dev > environments I work in) I have a server with a bunch of mates that I > trust to run anything as root. However, as I also change passwords > randomly and regularly and this includes the root password, I have > each user setup in the sudoers file so they can run anything as root - > including (and the most popular) sudo su - in order to become root. > > I don't particularly care about logging what they do as I trust them > (as is the case at work as well in our development environments) and > to some degree, anyone that you give access to commands that run as > the root user will require some level of trust. If this person is > caught 'hacking' or 'gaining privileges above their station' then your > workplace code of conduct should come into effect - no longer a > technical problem. (in my case its delete their account and boot them > off the box until such time as they feel suitably contrite) > > If you usage of the word 'op' refers to the original poster, then > you'd see that this person (obviously) has the ability to edit the > sudoers file and is wondering why, after he set it up, it was asking > for a password and not accepting his user one, to which it was pointed > out that he has possibly miss configured sudo adding an option to > sudoers that requests roots password not the users one. If this user > already has root in order to edit sudoers, why would you jump to the > conclusion that he is trying to 'hack' his own box ? trying to gain > privs higher than root ? um.. right. > > Either way, I think you are stretching a little to come to the > conclusion that by using 'sudo su -' the 'op' is trying to hack the > box. > > Just my $0.05 > > -- > Steve. > > -- > redhat-list mailing list > unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list > i'm paid to be suspicious! since this is a mailing list, the context clues lean to "original poster" it does seem that the original poster may be the computer operator, so both may apply regardless, the op and the other op are apparently trying to hack the system. unexplained actions should raise red flags for systems administrator (as well as others). now it seems highly ironic that all those having problems with what i wrote never asked the "op" (take your pick) about his motivation. blithely ignored that part. next time you think about complaining that your boss/lead/vp/pres "killed the bearer of bad news", don't; it would be hypocritical to complain that you got clobbered when you're clobbering me! of course, it could be a case of "the lady doth protest too much"! LOL! -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list