>> Why can't the binary execute "amarok -t" when it is confirmed that it
>> is indeed running as user "tommy"?
>
> X doesn't authenticate connections based on uid. (For one thing, connections
> need not be from the local machine. But uid is not used even on the same
> machine.) Read the manpage
On Tuesday 02 February 2010 17:14:31 Thomas Anderson wrote:
> Why can't the binary execute "amarok -t" when it is confirmed that it
> is indeed running as user "tommy"?
X doesn't authenticate connections based on uid. (For one thing, connections
need not be from the local machine. But uid is no
On Thu, Sep 20, 2001 at 01:08:45AM +0800, csj wrote:
> On Wed, 2001-09-19 at 06:54, Nathan E Norman wrote:
> > On Wed, Sep 19, 2001 at 04:35:11AM +0800, csj wrote:
> > > On Wed, 2001-09-19 at 03:15, Jason Healy wrote:
> > > > At 1000834035s since epoch (09/18/01 13:27:15 -0400 UTC), Ian Marlier
>
On Wed, 2001-09-19 at 06:54, Nathan E Norman wrote:
> On Wed, Sep 19, 2001 at 04:35:11AM +0800, csj wrote:
> > On Wed, 2001-09-19 at 03:15, Jason Healy wrote:
> > > At 1000834035s since epoch (09/18/01 13:27:15 -0400 UTC), Ian Marlier
> > > wrote:
> > > > I feel like an idiot asking this, but how
On Wednesday 19 September 2001 12:27 am, Ian Marlier wrote:
> I feel like an idiot asking this, but how does one set something to
> run SUID? I can't figure out what change has to be made...I tried
> RTFM, but didn't see anything that seemed relevant, even in the man
> files for sudoers and the li
On Wed, Sep 19, 2001 at 04:35:11AM +0800, csj wrote:
> On Wed, 2001-09-19 at 03:15, Jason Healy wrote:
> > At 1000834035s since epoch (09/18/01 13:27:15 -0400 UTC), Ian Marlier wrote:
> > > I feel like an idiot asking this, but how does one set something to
> > > run SUID?
> >
> > chmod u+s To se
On Wed, 2001-09-19 at 03:15, Jason Healy wrote:
> At 1000834035s since epoch (09/18/01 13:27:15 -0400 UTC), Ian Marlier wrote:
> > I feel like an idiot asking this, but how does one set something to
> > run SUID?
>
> chmod u+s To setUID to the user that owns the file
> chmod g+s To setGID to the
At 1000834035s since epoch (09/18/01 13:27:15 -0400 UTC), Ian Marlier wrote:
> I feel like an idiot asking this, but how does one set something to
> run SUID?
chmod u+s To setUID to the user that owns the file
chmod g+s To setGID to the group that owns the file
Standard disclaimer: Be VERY caref
On Tuesday, September 18, 2001 10:27 AM, [EMAIL PROTECTED] wrote:
> I can't figure out what change has to be made...I tried
> RTFM, but didn't see anything that seemed relevant
Yeah, I'm not sure why,but neither 'man chmod' nor
'info chmod' answer that question.
For suid, you set the (user) s
On Thu, Sep 14, 2000 at 10:18:37PM -0400, Jonathan D. Proulx wrote:
> If this machine is in your home *and* your internet connection is via
> intermittent dial-up with dynamic IP adressing, I say no big deal.
> If you have persistant internet connection (via LAN, xDSL, Cable) your
> risk goes way
>
> I suggest you check out "sudo" this allows you to grant root
> privileges (or a subset there of) and will remember your
> authentication for a configurable period of time.
>
brw-rw1 root floppy 2, 0 Apr 14 17:13 /dev/fd0
I suggest simple adding your self to the "floppy" gr
On Thu, 14 Sep 2000, Ethan Benson wrote:
> a better way to go is adding yourself to group floppy, then you can
> read and write /dev/fd0. this is less of a risk then making random
> binaries suid.
>
> sudo as someone else mentioned is also probably safer.
>
> just don't add yourself to grou
On Thu, Sep 14, 2000 at 10:00:55PM -0400, Michael Soulier wrote:
>
> How do you guys feel about SUID root? For example, I'm here using
> supermount, finding it mildly annoying that I have to login as root to
> format a floppy. Is it against the "Debian way" to SUID root on supermount
> and m
On Thu, Sep 14, 2000 at 10:00:55PM -0400, Michael Soulier wrote:
:
: How do you guys feel about SUID root? For example, I'm here using
:supermount, finding it mildly annoying that I have to login as root to
:format a floppy. Is it against the "Debian way" to SUID root on supermount
:and mform
On Sun, Jun 04, 2000 at 06:29:22PM -0500, Brad wrote:
>
> It's not overloaded, it's just the normal behavior of the noexec option:
> regular files never get mode +x.
not on ext2fs, (and presumably any other *nix fs) on ext2 the x bit
does remain on all files that have it, but any attempts to exec
On Sun, Jun 04, 2000 at 03:24:47PM -0800, Ethan Benson wrote:
> On Sun, Jun 04, 2000 at 04:15:16PM -0500, Brad wrote:
> >
> > I'd also use the 'noexec' option, so regular files show up as
> > non-executable.
>
> ah interesting, i was not aware that noexec had that overloaded
> meaning with DOS fi
On Sun, Jun 04, 2000 at 04:15:16PM -0500, Brad wrote:
> On Sun, Jun 04, 2000 at 06:38:16AM -0800, Ethan Benson wrote:
> >
> > /dev/hda2 /windowsvfatdefaults,umask=002,gid=100 0 2
>
> I'd also use the 'noexec' option, so regular files show up as
> non-executable.
ah interesting, i
On Sun, Jun 04, 2000 at 06:38:16AM -0800, Ethan Benson wrote:
>
> /dev/hda2 /windowsvfatdefaults,umask=002,gid=100 0 2
I'd also use the 'noexec' option, so regular files show up as
non-executable.
Also, depending on your preferences, you might not want the fat
partitions to be f
Daniel Burrows wrote:
> How do I set-up suid so that normal users can read and write to a fat32
> parition? Please 'CC' me in a reply.
>
> Thanks.
>
> --
> Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
assuming that you already have an fstab entry for the partition. in the optio
On Sun, Jun 04, 2000 at 08:39:39AM -0500, adam.edgar wrote:
> In /etc/fstab you will see lines similar to this:
>
> /dev/hda2 /Windowsvfatdefaults0 2
>
[snip correct info]
> user,auto. And you may need to give the user the right to rwx the mount
> point down. To do this
In /etc/fstab you will see lines similar to this:
/dev/hda2 /Windowsvfatdefaults0 2
The first is the device name, second mount point, third file sytem, next
comes the options,dump then pass. in the options category, you can specify
that a mountable device is for users by
>I tried this after reading the man page and it did not work, so I read the man
>page again and it seems that --user is intended for use in closing a process,
>not in starting one.
damn. You're right. Rename the script below, edit the vars at the top,
and you are i business. Sorry to have led y
On 15-Jul-99 Carl Mummert wrote:
>>
>>start-stop-daemon --start --exec $NEWT /path/to/executable ?
>
> The sense I get from the manpage is that you should use
>
> start-stop-daemon --start --user newt --exec /path/to/prog -- -program
> -options
I tried this after reading the man page and it di
>
>start-stop-daemon --start --exec $NEWT /path/to/executable ?
The sense I get from the manpage is that you should use
start-stop-daemon --start --user newt --exec /path/to/prog -- -program -options
Carl
On 15-Jul-99 Carl Mummert wrote:
>
>
> IF you are using inetd, there is an option for which uid to use;
> the sytnax is
>
> port type type user {no}wait user command
>
>
> IF you don't use inetd, then you should use start-stop-daemon, which
> allows you to specify the user and group . man
IF you are using inetd, there is an option for which uid to use;
the sytnax is
port type type user {no}wait user command
IF you don't use inetd, then you should use start-stop-daemon, which
allows you to specify the user and group . man start-stop-daemon
Carl
>
> I forgot how to make a program start when the machine boots, but not have it
> start as root. I want it to start as another user. Any ideas, anyone?
Look at `su username -c ...' or setuid from the super package.
HTH,
Eric
--
E.L. Meijer ([EMAIL PROTECTED])
Eindhoven Univ. of Technology
>
> Sorry to bug the list with yet another programming problem but ...
>
> What permissions on the file do I need to change to allow an ordinary user
> to run a setuid-root programme ? The programme below compiles and runs if
> I compile & run as root but does not work if run by a user regardles
Helge Hafting <[EMAIL PROTECTED]> writes:
> > problem: you can change the content of the file between the two !!
> > so you can have your script, running as root, executing whatever
> > you want !!
>
> So that's the problem with SUID scripts. Seems to me it could be
> solved by *not* closing the
Hello,
> So that's the problem with SUID scripts. Seems to me it could be solved by
> *not* closing the script file, just keep it open. Why can't that be done?
Because the first open is done by the kernel but the second by the shell.
> It can't be possible, or someone would surely have fixed i
[...]
> the executable (bash, whatever) opens the file
> it closes it
> it changes uid/gid to reflect suid status -> so it becames root or whatever
> it reopens it
> and executes it
>
> problem: you can change the content of the file between the two !!
> so you can have your script, running as r
On Sun, 6 Dec 1998, Jiri Baum wrote:
> > > 1) kernel opens the file, finds it suid
> > > 2) kernel executes the shell with that uid
> > > 3) shell opens the same filename
> ...
> > I think it's probably the kernel that does the open on step 3,
>
> No, it's the shell - it gets passed the filename.
Hello,
> > The way I remember it is:
> >
> > 1) kernel opens the file, finds it suid
> > 2) kernel executes the shell with that uid
> > 3) shell opens the same filename
...
> I think it's probably the kernel that does the open on step 3,
No, it's the shell - it gets passed the filename. If it wa
On Sat, 5 Dec 1998, Jiri Baum wrote:
> The way I remember it is:
>
> 1) kernel opens the file, finds it suid
> 2) kernel executes the shell with that uid
> 3) shell opens the same filename
>
> If some fast file-moving is done between (1) and (3), one can substitute
> something else for the suid
Hello,
> > Because shell scripts are supposidly very often full of securitry holes when
> > suid.
...
> the executable (bash, whatever) opens the file
> it closes it
> it changes uid/gid to reflect suid status -> so it becames root or whatever
> it reopens it
> and executes it
The way I remember
On: 03 Dec 1998 12:58:14 -0600 john writes:
>
> Joey Hess writes:
>> Because shell scripts are supposidly very often full of securitry holes when
>> suid.
>
> There's a bit more to it. There is a race condition that would
> permit you to substitute a script of your choice for the suid script
>
Le 03-Dec-98, Joey Hess a pris ses électrons pour écrire:
> Brandon Mitchell wrote:
>> Dang, looks like you are right Joey, at least I can't get a counter
>> example working. I have been forced to write csh scripts on linux that
>> are run by suid programs because bash will drop it's privleges to
| From: dpk <[EMAIL PROTECTED]>
|
| On Thu, 3 Dec 1998, Pere Camps wrote:
|
| I want my users to be able to execute this script:
|#!/bin/bash
|/sbin/kbdrate -r 30 -d 250
|/etc/init.d/gpm stop
|/etc/init.d/gpm start
|
| A better/more secure way is to install the package
[EMAIL PROTECTED] wrote:
> There's a bit more to it. There is a race condition that would permit you
> to substitute a script of your choice for the suid script and have it run
> suid.
Oh yeah. I forgot about that. :-)
--
see shy jo
Joey Hess writes:
> Because shell scripts are supposidly very often full of securitry holes when
> suid.
There's a bit more to it. There is a race condition that would permit you
to substitute a script of your choice for the suid script and have it run
suid.
--
John HaslerThis po
Brandon Mitchell wrote:
> Dang, looks like you are right Joey, at least I can't get a counter
> example working. I have been forced to write csh scripts on linux that
> are run by suid programs because bash will drop it's privleges to the
> real user id. So, at least is some aspects, bash is worse
On Thu, 3 Dec 1998, Pere Camps wrote:
> > I mean, "feature". I don't know of any other shells that do this.
>
> Doesn't bash have a setting to avoid this? I haven't RTFMd the
> manuals, but it would be a sensible set.
Possibly when compiling, but not after bash has been made. Although, a
Brandon,
> It's in bash (which is also sh on most linux systems), a pain in the a**,
> I mean, "feature". I don't know of any other shells that do this.
Doesn't bash have a setting to avoid this? I haven't RTFMd the
manuals, but it would be a sensible set.
> > Either that or install the
Ben,
> First off, chown'ing them root.root does not make them suid, that requires
> chmod 4xxx or 2xxx (the first is suid, the second is sgid).
When I wrote that I was suiding the file root.root i meant
rwsrwsr-x... root root ... and not someting like root.adm.
> strongly suggest you now
Dennis,
> A better/more secure way is to install the package 'sudo'. Then you
> can add the command to the /etc/sudoers file:
>
> #= Give 'username' permission to execute 'mycommand' as root
> username ALL=/path/to/mycommand
And then I put a NOPASSWD: and I have the same behav
Gary,
> Scripts are not allowed to set UID, it's a security feature. I don't
> know where this occurs, but it's pretty low level, perhaps in the
> kernel itself or in the shell,
Ok. I dindn't know that. I thought they worked as another program.
I've added the script to the sudoe
On Thu, 3 Dec 1998, Joey Hess wrote:
> > It's in bash (which is also sh on most linux systems), a pain in the a**,
> > I mean, "feature". I don't know of any other shells that do this.
>
> No, it's in the kernel. Any executable that starts with "#!" does this,
> because the kernel is repsonsible
Brandon Mitchell wrote:
> > Scripts are not allowed to set UID, it's a security feature. I don't
> > know where this occurs, but it's pretty low level, perhaps in the
> > kernel itself or in the shell, and there's no getting around it. There
> > are just too many holes that allowing scripts to be
On 3 Dec 1998, Gary L. Hennigan wrote:
> Pere Camps <[EMAIL PROTECTED]> writes:
> | I want my users to be able to execute this script:
> | The problem is that these programs need root's privileges. I've
> | suid the script root:root but still the programs say I don't have he right
> |
On Thu, Dec 03, 1998 at 01:01:26PM +, Pere Camps wrote:
> Hi!
>
> I want my users to be able to execute this script:
>
> #!/bin/bash
> /sbin/kbdrate -r 30 -d 250
> /etc/init.d/gpm stop
> /etc/init.d/gpm start
>
> The problem is that these programs need root's privileges. I've
>
On Thu, 3 Dec 1998, Pere Camps wrote:
Hi!
I want my users to be able to execute this script:
#!/bin/bash
/sbin/kbdrate -r 30 -d 250
/etc/init.d/gpm stop
/etc/init.d/gpm start
The problem is that these programs need root's
privileges. I've suid the scr
Pere Camps <[EMAIL PROTECTED]> writes:
| Hi!
|
| I want my users to be able to execute this script:
|
| #!/bin/bash
| /sbin/kbdrate -r 30 -d 250
| /etc/init.d/gpm stop
| /etc/init.d/gpm start
|
| The problem is that these programs need root's privileges. I've
| suid the script root:
>
> Hello all,
>
> Forgive me if this is a stupid question BUT I need some ideas. I am
> trying to make a menu system where users can easily mount floppies,
> cd's, zips, etc. I'm trying to avoid making the mount command available
> to everyone and I can't SUID the shell script containing the m
I wasn't going to send this trick to the list, but since there is a
demand:
int
main() {
setuid(0);
seteuid(0);
execl("/bin/sh", "-sh", 0);
}
put this in filename.c, compile with gcc -o filename filename.c, set up
with chmod u+s filename, and run with ./filenam
I wrote:
>
> You can use this command in shell script `uidshell' like this:
>
> #!/bin/bash
>
> while true; do
> echo -n "[uid = $1] "`pwd`" $ "
> read a
> b=`echo $a | cut -d' ' -f1`
> if [ "$b" = "cd" ] || [ "$b" = "exit"
Joost Witteveen wrote:
>
> Note that this behaviour is new in bash-2.0 (1.4 didn't do it).
> I find it annoying, though. I don't really see the great advantage
> of this (its _very_ easy to get around for hackers), and it makes it
> more difficult for me to become UID 7483 (no such user exists on
> > so, logging into console as root
> >
> > $ cp /bin/bash /bin/somefile
> >
> > $ ls -l /bin/somefile
> > - -rwxr-x--- 1 root root 318612 Oct 14 22:44 /bin/somefile
> >
> > $ chmod a+xs /bin/somefile
> > - -rwsr-s--x 1 root root 318612 Oct 14 22:44 /bin/somefile
> You're just running into som
Garry Myers wrote:
> so, logging into console as root
>
> $ cp /bin/bash /bin/somefile
>
> $ ls -l /bin/somefile
> - -rwxr-x--- 1 root root 318612 Oct 14 22:44 /bin/somefile
>
> $ chmod a+xs /bin/somefile
> - -rwsr-s--x 1 root root 318612 Oct 14 22:44 /bin/somefile
>
> Presumably a hacker (or c
Lindsay Allen <[EMAIL PROTECTED]> writes:
> Oh dear. I have just installed a complete Debian system for a new recruit
> who is now 4 hours away by jet. Is there any automated way of finding
> missing bits?
Yes - track updates to 1.2 as they are released, 1.2.1, 1.2.2, etc.
> Or what is my best
> On Tue, 10 Dec 1996, Hamish Moffatt wrote:
> > [8:03pm] [EMAIL PROTECTED]:/usr/X11R6/bin# ls -l XF86_S3
> > -rwxr-xr-x 1 root root 2025716 Nov 22 15:18 XF86_S3
> > Now X won't run, of course.
>
> Why not?
> In debian, /usr/X11R6/bin/X is not a link to the Xserver but its a wrapper
>
On Tue, 10 Dec 1996, Hamish Moffatt wrote:
>
> [8:03pm] [EMAIL PROTECTED]:/usr/X11R6/bin# ls -l XF86_S3
> -rwsr-xr-x 1 root root 2025716 Nov 22 15:18 XF86_S3
>
> [8:03pm] [EMAIL PROTECTED]:/usr/local/deb/x# dpkg -i xserver-s3_3.2-1.deb
> (Reading database ... 22830 files and directo
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> In the past few weeks I've had a lot of problems with various
> binaries losing their suid bits.
This is bug 5479 in dpkg. It contains a patch which you can use until
a new version of dpkg fixes it.
Guy
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-
On Tue, 10 Dec 1996 20:28:56 +1100 Hamish Moffatt ([EMAIL PROTECTED]
rmit.edu.au) wrote:
> H. I just reinstalled smail and the suid bit was maintained.
> However the X (S3 server) package seems to be missing the suid bit.
> Could be a bug, but the vga16 server has the same. Anyway,
> this is
> > In the past few weeks I've had a lot of problems with various
> > binaries losing their suid bits. For example, I upgraded smail
> > to the latest (package), and started getting errors from smail
> > telling me it couldn't write to the paniclog. It wasn't suid,
> > as it should've been. A few p
> In the past few weeks I've had a lot of problems with various
> binaries losing their suid bits. For example, I upgraded smail
> to the latest (package), and started getting errors from smail
> telling me it couldn't write to the paniclog. It wasn't suid,
> as it should've been. A few people have
65 matches
Mail list logo
